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

From Daniel Farina
Subject Re: Hard limit on WAL space used (because PANIC sucks)
Date
Msg-id CAAZKuFa7scBf+dFZ0qoUzhtcyjj7h3h2DXtNA=9FcOtADkzn3g@mail.gmail.com
Whole thread Raw
In response to Re: Hard limit on WAL space used (because PANIC sucks)  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Mon, Jun 10, 2013 at 4:42 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Daniel, Jeff,
>
>> I don't doubt this, that's why I do have a no-op fallback for
>> emergencies.  The discussion was about defaults.  I still think that
>> drop-wal-from-archiving-whenever is not a good one.
>
> Yeah, we can argue defaults for a long time.  What would be better is
> some way to actually determine what the user is trying to do, or wants
> to happen.  That's why I'd be in favor of an explict setting; if there's
> a setting which says:
>
> on_archive_failure=shutdown
>
> ... then it's a LOT clearer to the user what will happen if the archive
> runs out of space, even if we make no change to the defaults.  And if
> that setting is changeable on reload, it even becomes a way for users to
> get out of tight spots.

I like your suggestion, save one thing: it's not a 'failure' or
archiving if it cannot keep up, provided one subscribes to the view
that archiving is not elective.  I nit pick at this because one might
think this has something to do with a non-zero return code from the
archiving program, which already has a pretty alarmist message in
event of transient failures (I think someone brought this up on
-hackers but a few months ago...can't remember if that resulted in a
change).

I don't have a better suggestion that is less jargonrific though, but
I wanted to express my general appreciation as to the shape of the
suggestion.



pgsql-hackers by date:

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