Re: bgworker crashed or not?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: bgworker crashed or not?
Дата
Msg-id CA+Tgmoa047dAbaEToo6QUUTMhwi4QN+EnaM+DXgW7O-9zjm=0Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: bgworker crashed or not?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: bgworker crashed or not?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Tomas Vondra"
Дата:
Сообщение: Re: GIN improvements part2: fast scan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: slow startup due to LWLockAssign() spinlock