On 2014-04-16 10:37:12 -0400, Robert Haas wrote:
> On Wed, Apr 16, 2014 at 9:10 AM, Andres Freund <and...@2ndquadrant.com> wrote:
> >> Agreed, but after further reflection it seems like if you've declared
> >> a restart interval, then "done until restart interval" is probably the
> >> common case. So how about
> >> exit(0) - done until restart interval, or permanently if there is none
> >> exit(1) - done permanently, even if a restart interval was declared
> >> exit(other) - crash
> >> I don't offhand see a point in an "exit and restart immediately" case.
> >> Why exit at all, if you could just keep running? If you *can't* just
> >> keep running, it probably means you know you've bollixed something,
> >> so that the crash case is probably what to do anyway.
> > There's the case where you want to quickly go over all the databases,
> > but only use one bgworker for it. I don't think there's another way to
> > do that.
> > I think we really should bite the bullet and change this before 9.4
> > comes out. The current static bgworker facility has only been out there
> > for one release, and dynamic bgworkers aren't released yet at all. If we
> > wait with this for 9.5, we'll annoy many more people.
> So, exactly what do you want to change? If you want to keep the
> restart-immediately behavior, then that argues for NOT changing
I don't neccessarily want to keep that behaviour. It can be emulated
easily enough by setting the restart interval to 0. I just wanted to
explain that it's not completely unreasonable to want such a short
> I actually think the right answer here might be to give background
> workers a way to change their configured restart interval. We've
> already got a shared memory area that the postmaster reads to know how
> what to do when starting a dynamic background worker, so it probably
> wouldn't be that hard. But I'm not volunteering to undertake that on
> April 16th.
That seems like a separate feature - and I don't see a need to rush that
into 9.4. All I want that if we decide to change the API, we should do
What I dislike about the status quo is that the
1) The regular exit(0) behaves all but regular.
2) The only way to regularly exit is logged as a failure. Thus there's
no real way to flag a failure that's actually a failure.
So I think your proposal above already is an improvement upon the status
quo. Maybe we also should change the logging of bgworker exits.
I think we probably also need a way to exit that's treated as an error,
but doesn't lead to a PANIC restart.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: