Arjen van der Meijden <[EMAIL PROTECTED]> writes: > In the postgresql.log a write-failure messages was repeated enough to > make the log file 50MB larger:
> [ - 2005-09-07 13:03:47 CEST @] ERROR: xlog flush request 29/67713428 > is not satisfied --- flushed only to 29/2E73E488 > [ - 2005-09-07 13:03:47 CEST @] CONTEXT: writing block 21 of relation > 1663/2013826/9975789 > ... > TopMemoryContext: -1095880208 total in 264213 blocks; 537938888 free > (924739 chunks); -1633819096 used > MdSmgr: 8192 total in 1 blocks; 8024 free (0 chunks); 168 used > Pending Ops Table: 8192 total in 1 blocks; 6112 free (0 chunks); 2080 used > DynaHash: 8192 total in 1 blocks; 7488 free (0 chunks); 704 used > smgr relation table: 8192 total in 1 blocks; 4048 free (0 chunks); 4144 used > LockTable (locallock hash): 8192 total in 1 blocks; 6112 free (0 > chunks); 2080 used > ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used > [ - 2005-09-09 02:42:22 CEST @] ERROR: out of memory > [ - 2005-09-09 02:42:22 CEST @] DETAIL: Failed on request of size 16000. The pending-ops table only exists in the bgwriter, so it's evidently the bgwriter that was out of memory. I have an old note to myself : Doesn't bgwriter risk leaking memory if ereport out of a checkpoint? : Seems we should have it run checkpoints in a short-term context. : Don't the other daemons have similar issues? It looks to me like you have a case of this actually happening: it kept failing to execute a checkpoint and leaking some more memory each time. I'll move the priority of fixing that up a bit ... The other question is why the failure was occurring in the first place --- corrupt LSN value, apparently, but how'd it get that way? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster