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

From Robert Haas
Subject Re: [HACKERS] error handling in RegisterBackgroundWorker
Date
Msg-id CA+TgmoaNraTz3bjCt0GUQhEHZ6+VH-Gm3mLfyZJmzqqMQ57oGQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] error handling in RegisterBackgroundWorker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] error handling in RegisterBackgroundWorker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> 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.

I guess the question is whether people will prefer to have the
database start up and be missing the worker, or to have it not start.
As you point out, the former is likely to result in an eventual
restart, but the latter may lead to a longer period of downtime RIGHT
NOW.  People tend to really hate things that make the database not
start, so I'm not sure what's best here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Documentation improvements for partitioning
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Documentation improvements for partitioning