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

From Peter Eisentraut
Subject Re: [HACKERS] error handling in RegisterBackgroundWorker
Date
Msg-id 3bb07215-05e8-7750-d87c-ce07c62ba5cc@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] error handling in RegisterBackgroundWorker  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] error handling in RegisterBackgroundWorker  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 4/9/17 22:40, Noah Misch wrote:
> Agreed.  There are times when starting up degraded beats failing to start,
> particularly when the failing component has complicated dependencies.  In this
> case, as detailed upthread, this can only fail in response to basic
> misconfiguration.  It's not the kind of thing that will spontaneously fail
> after a minor upgrade, for example.

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?

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Repetitive code in RI triggers