To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: "Jeremy Haile" <jhaile@fastmail.fm>, pgsql-performance@postgresql.org
Subject: Re: URGENT: Out of disk space pg_xlog 
In-reply-to: <458BD182.EE98.0025.0@wicourts.gov> 
References: <1166803606.2828.281701761@webmail.messagingengine.com>
	<1166806378.10592.281708161@webmail.messagingengine.com>
	<458BC058.EE98.0025.0@wicourts.gov><458BC058.EE98.0025.0@wicourts.gov>
	<26238.1166811258@sss.pgh.pa.us>
	<458BD182.EE98.0025.0@wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Fri, 22 Dec 2006 12:37:23 -0600"
Date: Fri, 22 Dec 2006 13:46:10 -0500
Message-ID: <26666.1166813170@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
>> 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
 
> So, at this point, if space is freed on the data partition somehow,
> Postgres recovers with no problems?  (i.e.,, the database is still
> running and no requests have been terminated abnormally due to the space
> problems?)

Right, no committed transactions have been lost.  Depending on what you
are doing, you might see individual transactions fail due to
out-of-space --- an INSERT/UPDATE that couldn't find free space within
its table would probably fail while trying to extend the table, and
anything requiring a large temp file would fail.
 
> Just to confirm what I would assume at this point -- non-committed
> transactions should roll back cleanly; it is reasonable to assume no
> corruption at this point?

Yeah, I would expect no problems.

			regards, tom lane