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 6: explain analyze is your friend
