Re: [HACKERS] error handling in RegisterBackgroundWorker - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] error handling in RegisterBackgroundWorker
Date
Msg-id 30852.1491880958@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] error handling in RegisterBackgroundWorker  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] error handling in RegisterBackgroundWorker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: [HACKERS] error handling in RegisterBackgroundWorker  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [pgsql-www] [HACKERS] Small issue in online devel documentationbuild
Next
From: Osahon Oduware
Date:
Subject: [HACKERS] PostGIS Raster - Loading MrSID format