On 30/04/14 23:35, Robert Haas wrote:
> On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>> On 28/04/14 16:27, Robert Haas wrote:
>>>
>>> It seems we have consensus on what to do about this, but what we
>>> haven't got is a patch.
>>
>> If you mean the consensus that exit status 0 should mean permanent stop then
>> I think the patch can be as simple as attached.
>
> Hmm. Well, at the very least, you need to update the comment.
>
Obviously, also docs, the above was just demonstration that the patch is
simple (and also all I could manage to write and test on the way from
airport to hotel).
The attached patch is more proper.
One thing I hit during going through the code is the quickdie handler.
Originally it exited with exit code 0 so that bgworker was always
restarted immediately, but since we changed meaning of exit code 0 to
keep bgworker dead forever I changed the exit code in quickdie to 2
which seems to be consistent with how other backends work. One side
effect is that when we get to normal backed crash recovery where
everything gets restarted, bgworker restart will be affected by
bgw_restart_time.
This should hopefully not be too big issue for normal bgworkers as it's
an exceptional situation. And for dynamic bgworkers this is probably
more proper behavior anyway since currently they would get restarted
immediately without their parent process knowing about them anymore (as
it also got restarted). The above BTW leads me to thinking that we might
want to include a note somewhere in the docs saying that for most
use-cases dynamic bgworkers should use bgw_restart_time =
BGW_NEVER_RESTART (this is IMHO true for basically all use-cases except
where you use them as static ones and just need to run dynamic number of
them), but I didn't include such note in the patch.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services