Re: error handling in RegisterBackgroundWorker

On Mon, Apr 10, 2017 at 11:22:38PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)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.

Yep. I mentioned "complicated dependencies" as a factor, and that's relevant
to the stats collector. While creating a loopback network socket is not
highly complicated, it does fail in the field, and the user owning PostgreSQL
may lack the means to fix it. RegisterBackgroundWorker() failure, on the
other hand, implies the DBA changed a PGC_POSTMASTER setting like
shared_preload_libraries or max_logical_replication_workers without raising
max_worker_processes. Best to get unmistakable feedback and immediately raise
max_worker_processes or rollback the causative GUC change.

> 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?

Maybe. I share Peter's doubts. Also, not all degradation is equal, and one
user may cherish worker A alone while another user cherishes worker B alone.
Still, maybe.