On 2014-02-03 11:29:22 -0500, Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> So
> >> exit(0) - done, permanently
> >> exit(1) - done until restart interval
> >> exit(other) - crash
> >> and there's no way to obtain the "restart immediately" behavior?
> > That's what I was thinking about, yes.  Of course, when the restart
> > interval is 0, "done until restart interval" is the same as "restart
> > immediately", so for anyone who wants to *always* restart immediately
> > there is no problem.  Where you will run into trouble is if you
> > sometimes want to wait for the restart interval and other times want
> > to restart immediately.  But I'm not sure that's a real use case.  If
> > it is, I suggest that we assign it some other, more obscure exit code
> > and reserve 0 and 1 for what I believe will probably be the common
> > cases.
> 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.


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to