On Wed, Apr 16, 2014 at 9:10 AM, Andres Freund <andres@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
exit(0).
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company