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

From Robert Haas
Subject Re: bgworker crashed or not?
Date
Msg-id CA+Tgmoa047dAbaEToo6QUUTMhwi4QN+EnaM+DXgW7O-9zjm=0Q@mail.gmail.com
Whole thread Raw
In response to Re: bgworker crashed or not?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: bgworker crashed or not?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So
>         exit(0) - done, permanently
>         exit(1) - done until restart interval
>         exit(other) - crash
> and there's no way to obtain the "restart immediately" behavior?

That's what I was thinking about, yes.  Of course, when the restart
interval is 0, "done until restart interval" is the same as "restart
immediately", so for anyone who wants to *always* restart immediately
there is no problem.  Where you will run into trouble is if you
sometimes want to wait for the restart interval and other times want
to restart immediately.  But I'm not sure that's a real use case.  If
it is, I suggest that we assign it some other, more obscure exit code
and reserve 0 and 1 for what I believe will probably be the common
cases.

It would be potentially more useful and more general to have a
function BackgroundWorkerSetMyRestartInterval() or similar.  That way,
a background worker could choose to get restarted after whatever
amount of time it likes in a particular instance, rather than only 0
or the interval configured at registration time.  But I'm not that
excited about implementing that, and certainly not for 9.4.  It's not
clear that there's a real need, and there are thorny questions like
"should a postmaster crash and restart cycle cause an immediate
restart?" and "what if some other process wants to poke that
background worker and cause it to restart sooner?".  There are lots of
interesting and potentially useful behaviors here, but I'm wary of
letting the engineering getting out ahead of the use cases.

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



pgsql-hackers by date:

Previous
From: "Tomas Vondra"
Date:
Subject: Re: GIN improvements part2: fast scan
Next
From: Tom Lane
Date:
Subject: Re: slow startup due to LWLockAssign() spinlock