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

From Andres Freund
Subject Re: Hard limit on WAL space used (because PANIC sucks)
Date
Msg-id 20130608182743.GA28471@awork2.anarazel.de
Whole thread Raw
In response to Re: Hard limit on WAL space used (because PANIC sucks)  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Hard limit on WAL space used (because PANIC sucks)
Re: Hard limit on WAL space used (because PANIC sucks)
List pgsql-hackers
On 2013-06-08 11:15:40 -0700, Joshua D. Drake wrote:
> To me, a more pragmatic approach makes sense. Obviously having some kind of
> code that checks the space makes sense but I don't know that it needs to be
> around any operation other than we are creating a segment. What do we care
> why the segment is being created? If we don't have enough room to create the
> segment, the transaction rollsback with some OBVIOUS not OBTUSE error.
> 
> Obviously this could cause a ton of transactions to roll back but I think
> keeping the database consistent and rolling back a transaction in case of
> error is exactly what we are supposed to do.

You know, the PANIC isn't there just because we like to piss of
users. There's actual technical reasons that don't just go away by
judging the PANIC as stupid.
At the points where the XLogInsert()s happens we're in critical sections
out of which we *cannot* ERROR out because we already may have made
modifications that cannot be allowed to be performed
partially/unlogged. That's why we're throwing a PANIC which will force a
cluster wide restart including *NOT* writing any further buffers from
s_b out.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Hard limit on WAL space used (because PANIC sucks)
Next
From: Andres Freund
Date:
Subject: Re: Hard limit on WAL space used (because PANIC sucks)