Re: error handling in RegisterBackgroundWorker

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: error handling in RegisterBackgroundWorker
Date: 2017-04-11 15:33:34
Message-ID: 10783.1491924814@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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".

> I think there is no clear agreement here, and no historically consistent
> behavior. I'm prepared to let it go and cross it off the list of open
> items. I believe we should keep thinking about it, but it's not
> something that has to hold up beta.

Agreed, this doesn't seem like a must-fix-for-beta consideration.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2017-04-11 15:35:45 Re: Merge join for GiST
Previous Message Andrew Dunstan 2017-04-11 15:32:34 TAP tests take a long time