Re: background worker and normal exit

Hi,

I found that the normal exit (i.e., with exit code 0) of bgworker
always leads to
the immediate restart of bgworker whatever bgw_restart_time is. Is
this intentional?
Not only crash but also normal exit should go along with bgw_restart_time?

I'm now writing the bgworker which is allowed to be running only
during recovery.
After recovery ends, that bgworker is expected to exit with code 0. I
was thinking
to avoid the restart of the bgworker after normal exit, by using
BGW_NEVER_RESTART.

Regards,

--
Fujii Masao

On Sun, May 26, 2013 at 6:16 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> I found that the normal exit (i.e., with exit code 0) of bgworker
> always leads to
> the immediate restart of bgworker whatever bgw_restart_time is. Is
> this intentional?
>
Yes, per the docs:
http://www.postgresql.org/docs/devel/static/bgworker.html
"Background workers are expected to be continuously running; if they exit
cleanly, postgres will restart them immediately."

> Not only crash but also normal exit should go along with bgw_restart_time?
>
bgw_restart_time corresponds to the time a bgworker is restarted in case of
a crash only.

> I'm now writing the bgworker which is allowed to be running only
> during recovery.
> After recovery ends, that bgworker is expected to exit with code 0. I
> was thinking
> to avoid the restart of the bgworker after normal exit, by using
> BGW_NEVER_RESTART.
>
This flag makes a worker not to restart only in case of a crash. To solve
your problem, you could as well allow your process to restart and put it in
indefinite sleep if server is not in recovery such it it will do nothing in
your case.

Regards,
--
Michael

--On 26. Mai 2013 11:38:55 +0900 Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:

>
> This flag makes a worker not to restart only in case of a crash. To solve
> your problem, you could as well allow your process to restart and put it
> in indefinite sleep if server is not in recovery such it it will do
> nothing in your case.

Hmm so you can't have workers just "doing something once" and exit? I have
to admit, i didn't follow bgworkers closely in the past, but could you give
a short insight on why this is currently not possible?

--
Thanks

Bernd

On Mon, May 27, 2013 at 2:04 AM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:

>
>
> --On 26. Mai 2013 11:38:55 +0900 Michael Paquier <
> michael(dot)paquier(at)gmail(dot)com> wrote:
>
>
>> This flag makes a worker not to restart only in case of a crash. To solve
>> your problem, you could as well allow your process to restart and put it
>> in indefinite sleep if server is not in recovery such it it will do
>> nothing in your case.
>>
>
> Hmm so you can't have workers just "doing something once" and exit? I have
> to admit, i didn't follow bgworkers closely in the past, but could you give
> a short insight on why this is currently not possible?
>
Bgworkers are expected to run all the time, and will be restarted each time
they exit cleanly with a status code 0. Note that they are *still*
restarted immediately even if bgw_restart_time is set at BGW_NEVER_RESTART
or to a certain value.
There are actually two ways you can use to have them perform a one-time
task:
- put it in indefinite sleep after the task is accomplished
- set bgw_restart_time to BGW_NEVER_RESTART. and have the bgworler exit
with non-0 status code.

Regards,
--
Michael

On Sun, May 26, 2013 at 6:48 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
>> Hmm so you can't have workers just "doing something once" and exit? I have
>> to admit, i didn't follow bgworkers closely in the past, but could you give
>> a short insight on why this is currently not possible?
>
> Bgworkers are expected to run all the time, and will be restarted each time
> they exit cleanly with a status code 0. Note that they are *still* restarted
> immediately even if bgw_restart_time is set at BGW_NEVER_RESTART or to a
> certain value.
> There are actually two ways you can use to have them perform a one-time
> task:
> - put it in indefinite sleep after the task is accomplished

That's not really the same thing...

> - set bgw_restart_time to BGW_NEVER_RESTART. and have the bgworler exit with
> non-0 status code.

That might be good enough, though.

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

On 2013-05-28 10:23:46 -0400, Robert Haas wrote:
> On Sun, May 26, 2013 at 6:48 PM, Michael Paquier
> > - set bgw_restart_time to BGW_NEVER_RESTART. and have the bgworler exit with
> > non-0 status code.
>
> That might be good enough, though.

I suggested that to Fujii at pgcon, and it seems to work for him. But I
think this sucks since you loose support for a restart upon a FATAL or
similar error. And you cannot mark that as something non-fatal in the
log. To this day I laugh about the following oddity in the xorg log:

[ 30.087] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 30.088] (--) RandR disabled

I really don't want to go there.

You actually can only return a 1 since everything else will tear down
the whole cluster...

We actually were discussing this recently:
http://archives.postgresql.org/message-id/20130423134833.GD8499%40alap2.anarazel.de

I think a separate return code for "exited gracefully, don't restart"
would be a good idea.

Greetings,

Andres Freund

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

On Tue, May 28, 2013 at 10:31 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-05-28 10:23:46 -0400, Robert Haas wrote:
>> On Sun, May 26, 2013 at 6:48 PM, Michael Paquier
>> > - set bgw_restart_time to BGW_NEVER_RESTART. and have the bgworler exit with
>> > non-0 status code.
>>
>> That might be good enough, though.
>
> I suggested that to Fujii at pgcon, and it seems to work for him. But I
> think this sucks since you loose support for a restart upon a FATAL or
> similar error. And you cannot mark that as something non-fatal in the
> log. To this day I laugh about the following oddity in the xorg log:
>
> [ 30.087] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
> [ 30.088] (--) RandR disabled
>
> I really don't want to go there.
>
> You actually can only return a 1 since everything else will tear down
> the whole cluster...
>
> We actually were discussing this recently:
> http://archives.postgresql.org/message-id/20130423134833.GD8499%40alap2.anarazel.de
>
> I think a separate return code for "exited gracefully, don't restart"
> would be a good idea.

Yeah. Or maybe the restart-timing/restart-when logic should just
apply to the exit(0) case as well. Not sure what the downside of that
would be.

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

On 2013-05-28 10:33:47 -0400, Robert Haas wrote:
> On Tue, May 28, 2013 at 10:31 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2013-05-28 10:23:46 -0400, Robert Haas wrote:
> >> On Sun, May 26, 2013 at 6:48 PM, Michael Paquier
> >> > - set bgw_restart_time to BGW_NEVER_RESTART. and have the bgworler exit with
> >> > non-0 status code.
> >>
> >> That might be good enough, though.
> >
> > I suggested that to Fujii at pgcon, and it seems to work for him. But I
> > think this sucks since you loose support for a restart upon a FATAL or
> > similar error. And you cannot mark that as something non-fatal in the
> > log. To this day I laugh about the following oddity in the xorg log:
> >
> > [ 30.087] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
> > [ 30.088] (--) RandR disabled
> >
> > I really don't want to go there.
> >
> > You actually can only return a 1 since everything else will tear down
> > the whole cluster...
> >
> > We actually were discussing this recently:
> > http://archives.postgresql.org/message-id/20130423134833.GD8499%40alap2.anarazel.de
> >
> > I think a separate return code for "exited gracefully, don't restart"
> > would be a good idea.
>
> Yeah. Or maybe the restart-timing/restart-when logic should just
> apply to the exit(0) case as well. Not sure what the downside of that
> would be.

Loosing the ability to restart a process where the reason for exiting
are non-fatal and shouldn't be logged noisily or are already logged. I
actually could use both capabilities.

Greetings,

Andres Freund

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