Re: [HACKERS] error handling in RegisterBackgroundWorker

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] error handling in RegisterBackgroundWorker
Дата
Msg-id CAKFQuwYxPTwfipaA-xqBUaO9jt7D9uRFvr2ywJn-pWu876bOwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] error handling in RegisterBackgroundWorker  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] error handling in RegisterBackgroundWorker
Список pgsql-hackers
On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] Reversed sync check in pg_receivewal
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] TAP tests take a long time