Re: bgworker crashed or not?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Antonin Houska <antonin(dot)houska(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Subject: Re: bgworker crashed or not?
Date: 2014-04-28 14:27:41
Message-ID: CA+TgmoY0FXMayR1HH+uD+hM8+CL5Xh8nf610Eps55oJSmsU5+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 04/17/2014 08:35 AM, Craig Ringer wrote:
>> On 04/17/2014 04:47 AM, Petr Jelinek wrote:
>>>
>>> Well the logging is just too spammy in general when it comes to dynamic
>>> bgworkers but that's easy to fix in the future, no need to make
>>> decisions for 9.4.
>>
>> Agreed - it's the *API* that we need sorted out for 9.4, and log output
>> isn't something Pg tends to consider part of the API.
>>
>>> However I really don't like that I have to exit with exit code 1, which
>>> is normally used as failure, if I want to shutdown my dynamic bgworker
>>> once it has finished the work. And this behavior is something we can set
>>> properly only once...
>>
>> As far as I can tell we have a couple of options:
>>
>> - Redefine what the exit codes mean so that exit 0 suppresses
>> auto-restart and exits silently. Probably simplest.
>
> I'm now strongly in favour of this alternative.
>
> I've just noticed that the bgworker control interfaces do not honour
> bgw.bgw_restart_time = BGW_NEVER_RESTART if you exit with status zero.
>
> This means that it's not simply a problem where you can't say "restart
> me if I crash, but not if I exit normally".
>
> You also can't even say "never restart me at all". Because
> "BGW_NEVER_RESTART" seems to really mean "BGW_NO_RESTART_ON_CRASH".
>
> This _needs_fixing before 9.4.

It seems we have consensus on what to do about this, but what we
haven't got is a patch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-28 14:30:22 Re: [COMMITTERS] pgsql: Can't completely get rid of #ifndef FRONTEND in palloc.h :-(
Previous Message Tom Lane 2014-04-28 14:17:22 Re: Composite Datums containing toasted fields are a bad idea(?)