Re: [HACKERS] error handling in RegisterBackgroundWorker

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] error handling in RegisterBackgroundWorker
Дата
Msg-id 30852.1491880958@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] error handling in RegisterBackgroundWorker  (Noah Misch <noah@leadboat.com>)
Ответы Re: [HACKERS] error handling in RegisterBackgroundWorker
Re: [HACKERS] error handling in RegisterBackgroundWorker
Список pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote:
>> If history had been different, we could have implemented, say,
>> autovacuum or walreceiver on the background worker framework.  I think
>> unifying some of that might actually be a future project.  Would it be
>> OK if these processes just logged a warning and didn't start if there
>> was a misconfiguration?

> No.  I can't think of any background worker so unimportant that I'd want the
> warning only.  Certainly, then, the ones you list are far too important.

Well, I dunno.  We allow the system to start without a functioning stats
collector (cf what happens if we fail to create a working loopback
socket).  But lack of stats will effectively disable autovacuum.  So at
the very least we have some inconsistent decisions here.

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?
        regards, tom lane



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [pgsql-www] [HACKERS] Small issue in online devel documentationbuild
Следующее
От: Osahon Oduware
Дата:
Сообщение: [HACKERS] PostGIS Raster - Loading MrSID format