A couple clarifications:
There were only a few network sockets open.
I'm told that the eventlog was reviewed for any events which
mgiht be related to the failures before it was cleared. They
found none, so that makes it fairly certain there was no 2020
event.
-Kevin
>>> "Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> >>>
There weren't a large number of connections -- it seemed to be
that the one big update query, by itself, would do this. It seemed
to get through a lot of rows before failing. This table is normally
"insert only" -- so it would likely be getting most or all of the space
for inserting the updated rows from extending the table. Also, the
only reasonable plan for this update would be a table scan, so
it is possible that the failure occurred some time after the scan got
to rows added by the update statement.
It appears that the techs cleared the eventlog when they
reconfigured the machine, so I can no longer check for events
from the failures. :-(
-Kevin
>>> "Magnus Hagander" <mha@xxxxxxxxxxxxxx> >>>
> None of this seems material, however. It's pretty clear that
> the problem was exhaustion of the Windows page pool. Our
> Windows experts have reconfigured the machine (which had been
> tuned for Sybase ASE). Their changes have boosted the page
> pool from 20,000 entries to 180,000 entries. We're
> continuing to test to ensure that the problem is not showing
> up with this configuration; but, so far, it looks good.
Nope, with these numbers it doesn't. I was looking for a reason as to
why it would exhaust the pool - such as a huge number of connections.
Which doesn't appear to be so :-(
Another thing that will affect this is if you have a lot of network
sockets open. Anything like that?
BTW; do you get any eventid 2020 in your eventlog?
> If we don't want to tell Windows users to make highly
> technical changes to the Windows registry in order to use
> PostgreSQL, it does seem wise to use retries, as has already
> been discussed on this thread.
Yeah, I think it's at least worth a try at that.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
