On 2014-01-22 18:19:25 -0600, Jim Nasby wrote:
> On 1/21/14, 6:46 PM, Andres Freund wrote:
> >On 2014-01-21 16:34:45 -0800, Peter Geoghegan wrote:
> >>>On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund<andres@2ndquadrant.com> wrote:
> >>>> >I personally think this isn't worth complicating the code for.
> >>>
> >>>You're probably right. However, I don't see why the bar has to be very
> >>>high when we're considering the trade-off between taking some
> >>>emergency precaution against having a PANIC shutdown, and an assured
> >>>PANIC shutdown
> >Well, the problem is that the tradeoff would very likely include making
> >already complex code even more complex. None of the proposals, even the
> >one just decreasing the likelihood of a PANIC, like like they'd end up
> >being simple implementation-wise.
> >And that additional complexity would hurt robustness and prevent things
> >I find much more important than this.
>
> If we're not looking for perfection, what's wrong with Peter's idea of
> a ballast file? Presumably the check to see if that file still exists
> would be cheap so we can do that before entering the appropriate
> critical section.
That'd be noticeably expensive. Opening/stat a file isn't cheap,
especially if you do it via filename and not via fd which we'd have to
do. I am pretty sure it would be noticeably in single client workloads,
but it'd damned sure will be noticeable on busy multi-socket workloads.
I still think doing the checks in the wal writer is the best bet,
setting a flag that can then cheaply be tested in shared memory. When
set it will cause any further action that will write xlog to error out
unless it's already in progress.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
