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

From Peter Eisentraut
Subject [HACKERS] error handling in RegisterBackgroundWorker
Date
Msg-id b7578aaf-726e-61a1-0011-943e92ad08ee@2ndquadrant.com
Whole thread Raw
Responses Re: [HACKERS] error handling in RegisterBackgroundWorker  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
If RegisterBackgroundWorker() (the non-dynamic kind that is only
loadable from shared_preload_libraries) fails to register the worker, it
writes a log message and proceeds, ignoring the registration request.  I
think that is a mistake, it should be a hard error.  The only way in
practice to fix the problem is to change shared_preload_libraries or
max_worker_processes, both requiring a restart anyway, so proceeding
without the worker is not useful.

Perhaps this kind of worker has not been widely used in practice, but we
now have the logical replication launcher registering that way, and the
auto-prewarm patch also proposes to add one.  If you run out of worker
slots before the launcher is supposed to start, it just logs a message
and doesn't start.  That seems prone to confuse.

Attached is a proposed patch (0002) to change the log level to ERROR.
The other patch (0001) gives some additional error context for the
log/error message that you get.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Ryan Murphy
Date:
Subject: [HACKERS] Does having a NULL column automatically exclude the table from thetupleDesc cache?
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Documentation improvements for partitioning