Re: bgworker crashed or not?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Antonin Houska <antonin(dot)houska(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bgworker crashed or not?
Date: 2014-02-03 16:21:21
Message-ID: CA+Tgmoa047dAbaEToo6QUUTMhwi4QN+EnaM+DXgW7O-9zjm=0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-02-03 16:22:45 Re: slow startup due to LWLockAssign() spinlock
Previous Message Tomas Vondra 2014-02-03 16:19:34 Re: GIN improvements part2: fast scan