On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> > On 4/10/17 23:22, Tom Lane wrote:
> >> Personally I'd err on the side of "starting up degraded is better than
> >> not starting at all".  Or maybe we should invent a GUC to let DBAs
> >> express their preference on that?
>
> > If we defaulted allow_degraded to yes, then users wouldn't find that
> > setting until they do start up degraded and want to fix things, in which
> > case they could just fix the settings that caused the degraded startup
> > in the first place.
>
> > If we defaulted to no, then I don't think any user would go in and
> > change it.  "Sure, I'll allow degraded startup.  That sounds useful."
>
> Well, they would change it when their server failed to start and they
> needed to start it rather than just rebuild from backups.  I'd be fine
> with defaulting it off.  I just don't want "can't make a loopback socket"
> to be equivalent to "you're screwed and you'll never see your data again".
>

‚ÄčA potential middle-ground is to start, but then only allow superuser
connections.  At least then if the configuration problem is sitting
postgresql.conf.auto the superuser can issue ALTER SYSETM to fix it; and
can be reassured that worse case they can at least see their data.

If that was a soft setting they could also run a function to enable normal
access if they so choose.  In effect its a "default to off" mode with an
easy way to force the system to become live - but without a GUC (so they
couldn't make the decision permanent...which seems like a feature)

David J.

Reply via email to