Tom Lane wrote: > "Kevin Grittner" <[EMAIL PROTECTED]> writes: > > As I understand it, the log space accumulates for the oldest transaction > > which is still running, and all transactions which started after it. > > No, pg_xlog can be truncated as soon as a checkpoint occurs. If Jeremy > wasn't using archive_command then the only possible explanation for > bloated pg_xlog is that checkpoints were failing. Which is not unlikely > if the *data* partition runs out of space. Were there gripes in the log > before the system crash? The scenario we've seen in the past is > > * data partition out of space, so writes fail > * each time Postgres attempts a checkpoint, writes fail, so the > checkpoint fails. No data loss at this point, the dirty buffers > just stay in memory. > * pg_xlog bloats because we can't truncate away old segments > * eventually pg_xlog runs out of space, at which point we PANIC > and can't continue running the database > > Once you free some space on the data partition and restart, you should > be good to go --- there will be no loss of committed transactions, since > all the operations are in pg_xlog. Might take a little while to replay > all that log though :-(
Amazing that all works. What I did not see is confirmation from the user that the data directory filled up _before_ pg_xlog filled up. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
