Re: Hard limit on WAL space used (because PANIC sucks)
От | Jeff Janes |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | CAMkU=1wjB+rE4Yn6fBou0WrpfA3r2gZpTfL4Tcc_Mex1o8e41g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Hard limit on WAL space used (because PANIC sucks)
|
Список | pgsql-hackers |
On Sat, Jun 8, 2013 at 11:27 AM, Andres Freund <andres@2ndquadrant.com> wrote:
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.
If archiving is on and failure is due to no space, could we just keep trying XLogFileInit again for a couple minutes to give archiving a chance to do its things? Doing that while holding onto locks and a critical section would be unfortunate, but if the alternative is a PANIC, it might be acceptable.
The problem is that even if the file is only being kept so it can be archived, once archiving succeeds I think the file is not removed immediately but rather not until the next checkpoint, which will never happen when the locks are still held.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: