Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-12 Thread Robert Haas
On Tue, Apr 11, 2017 at 10:13 PM, Noah Misch wrote: > On Tue, Apr 11, 2017 at 11:33:34AM -0400, Tom Lane wrote: >> Peter Eisentraut writes: >> > I think there is no clear agreement here, and no historically consistent >> > behavior. I'm

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread Tom Lane
"David G. Johnston" writes: > On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: >> On 4/11/17 11:47, David G. Johnston wrote: >>> ​A potential middle-ground is to start, but then only allow superuser >>> connections. >>

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread Noah Misch
On Mon, Apr 10, 2017 at 11:22:38PM -0400, Tom Lane wrote: > Noah Misch 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

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread Noah Misch
On Tue, Apr 11, 2017 at 11:33:34AM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > I think there is no clear agreement here, and no historically consistent > > behavior. I'm prepared to let it go and cross it off the list of open > > items. I believe we

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread David G. Johnston
On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/11/17 11:47, David G. Johnston wrote: > > ​A potential middle-ground is to start, but then only allow superuser > > connections. > > Then you might as well start and allow all connections. I

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread Peter Eisentraut
On 4/11/17 11:47, David G. Johnston wrote: > ​A potential middle-ground is to start, but then only allow superuser > connections. Then you might as well start and allow all connections. I don't see what this buys. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread David G. Johnston
On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane wrote: > Peter Eisentraut writes: > > On 4/10/17 23:22, Tom Lane wrote: > >> Personally I'd err on the side of "starting up degraded is better than > >> not starting at all". Or maybe we should

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread Tom Lane
Peter Eisentraut writes: > On 4/10/17 23:22, Tom Lane wrote: >> 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? > If we defaulted

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-11 Thread Peter Eisentraut
On 4/10/17 23:22, Tom Lane wrote: > 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? If we defaulted allow_degraded to yes, then users wouldn't find that setting until

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-10 Thread Tom Lane
Noah Misch 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

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-10 Thread Noah Misch
On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote: > 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

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-10 Thread Peter Eisentraut
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

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-04-09 Thread Noah Misch
On Wed, Mar 29, 2017 at 04:58:40PM -0300, Alvaro Herrera wrote: > Robert Haas wrote: > > On Wed, Mar 29, 2017 at 2:10 PM, Peter Eisentraut > > wrote: > > > How specifically would we do that? And what user would choose the > > > behavior "start this background

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-03-29 Thread Alvaro Herrera
Robert Haas wrote: > On Wed, Mar 29, 2017 at 2:10 PM, Peter Eisentraut > wrote: > > How specifically would we do that? And what user would choose the > > behavior "start this background worker but don't worry if it doesn't work"? > > Well, if the background

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-03-29 Thread Robert Haas
On Wed, Mar 29, 2017 at 2:10 PM, Peter Eisentraut wrote: > How specifically would we do that? And what user would choose the > behavior "start this background worker but don't worry if it doesn't work"? Well, if the background worker is auto-prewarm, you'd

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-03-29 Thread Peter Eisentraut
On 3/24/17 02:33, Michael Paquier wrote: > What if we just let the user choose what they want with a new switch > in bgw_flags, but keep LOG the default? One behavior and the other > look both sensible to me. How specifically would we do that? And what user would choose the behavior "start this

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-03-24 Thread Michael Paquier
On Fri, Mar 24, 2017 at 1:20 PM, Peter Eisentraut wrote: > On 2/15/17 12:11, Robert Haas wrote: >> On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut >> wrote: >>> If RegisterBackgroundWorker() (the non-dynamic kind that is only

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-03-23 Thread Peter Eisentraut
On 2/15/17 12:11, Robert Haas wrote: > On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut > wrote: >> If RegisterBackgroundWorker() (the non-dynamic kind that is only >> loadable from shared_preload_libraries) fails to register the worker, it >> writes a log

Re: [HACKERS] error handling in RegisterBackgroundWorker

2017-02-15 Thread Robert Haas
On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut 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

[HACKERS] error handling in RegisterBackgroundWorker

2017-02-15 Thread Peter Eisentraut
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