Re: Hard limit on WAL space used (because PANIC sucks) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hard limit on WAL space used (because PANIC sucks)
Date
Msg-id 30263.1390325701@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hard limit on WAL space used (because PANIC sucks)  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hard limit on WAL space used (because PANIC sucks)  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Hard limit on WAL space used (because PANIC sucks)  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 6 June 2013 16:00, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
>> The current situation is that if you run out of disk space while writing
>> WAL, you get a PANIC, and the server shuts down. That's awful.

> I don't see we need to prevent WAL insertions when the disk fills. We
> still have the whole of wal_buffers to use up. When that is full, we
> will prevent further WAL insertions because we will be holding the
> WALwritelock to clear more space. So the rest of the system will lock
> up nicely, like we want, apart from read-only transactions.

I'm not sure that "all writing transactions lock up hard" is really so
much better than the current behavior.

My preference would be that we simply start failing writes with ERRORs
rather than PANICs.  I'm not real sure ATM why this has to be a PANIC
condition.  Probably the cause is that it's being done inside a critical
section, but could we move that?

> Instead of PANICing, we should simply signal the checkpointer to
> perform a shutdown checkpoint.

And if that fails for lack of disk space?  In any case, what you're
proposing sounds like a lot of new complication in a code path that
is necessarily never going to be terribly well tested.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
Next
From: Robert Haas
Date:
Subject: Re: array_length(anyarray)