error handling in RegisterBackgroundWorker

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: error handling in RegisterBackgroundWorker
Date: 2017-02-15 16:30:47
Message-ID: b7578aaf-726e-61a1-0011-943e92ad08ee@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
0001-Add-errcontext-to-background-worker-registration.patch text/x-patch 1.0 KB
0002-Change-failures-in-RegisterBackgroundWorker-to-hard-.patch text/x-patch 2.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-02-15 16:34:11 Re: Documentation improvements for partitioning
Previous Message Ryan Murphy 2017-02-15 16:29:36 Does having a NULL column automatically exclude the table from the tupleDesc cache?