Skip site navigation (1) Skip section navigation (2)

Re: URGENT: Out of disk space pg_xlog

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Jeremy Haile" <jhaile(at)fastmail(dot)fm>, pgsql-performance(at)postgresql(dot)org
Subject: Re: URGENT: Out of disk space pg_xlog
Date: 2006-12-22 18:46:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

pgsql-performance by date

Next:From: ohpDate: 2006-12-22 18:47:05
Subject: Re: URGENT: Out of disk space pg_xlog
Previous:From: Kevin GrittnerDate: 2006-12-22 18:37:23
Subject: Re: URGENT: Out of disk space pg_xlog

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group