Re: error handling in RegisterBackgroundWorker

On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.