Re: bgworker crashed or not? - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: bgworker crashed or not?
Date
Msg-id 536A426A.9080708@2ndquadrant.com
Whole thread Raw
In response to Re: bgworker crashed or not?  (Petr Jelinek <petr@2ndquadrant.com>)
List pgsql-hackers
On 07/05/14 02:25, Petr Jelinek wrote:
> On 06/05/14 19:05, Robert Haas wrote:
>> What I'm inclined to do is change the logic so that:
>>
>> (1) After a crash-and-restart sequence, zero rw->rw_crashed_at, so
>> that anything which is still registered gets restarted immediately.
>
> Yes, that's quite obvious change which I missed completely :).
>
>> (2) If a shmem-connected backend fails to release the deadman switch
>> or exits with an exit code other than 0 or 1, we crash-and-restart.  A
>> non-shmem-connected backend never causes a crash-and-restart.
>
> +1
>
>> (3) When a background worker exits without triggering a
>> crash-and-restart, an exit code of precisely 0 causes the worker to be
>> unregistered; any other exit code has no special effect, so
>> bgw_restart_time controls.
>
> +1
>

Ok, attached patch is my try at the proposed changes.

I don't like the reset_bgworker_crash_state function name, maybe you'll
come up with something better...

I passes my tests for the desired behavior, hopefully I didn't miss some
scenario.

--
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Next
From: Craig Ringer
Date:
Subject: Re: PGDLLEXPORTing all GUCs?