Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Дата
Msg-id CAEepm=298omvRS2C8WO=Cxp+WcM-Vn8V3x4_QhxURhKTRCSfYg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Wed, Apr 11, 2018 at 12:47 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Apr 11, 2018 at 12:26 PM, Andres Freund <andres@anarazel.de> wrote:
>> On 2018-04-11 12:17:14 +1200, Thomas Munro wrote:
>>> I arrived at this idea via the realisation that the closest thing to
>>> prctl(PR_SET_PDEATHSIG) on BSD-family systems today is
>>> please-tell-my-kqueue-if-this-process-dies.  It so happens that my
>>> kqueue patch already uses that instead of the pipe to detect
>>> postmaster death.  The only problem is that you have to ask it, by
>>> calling it kevent().  In a busy loop like those two, where there is no
>>> other kind of waiting going on, you could do that by calling kevent()
>>> with timeout = 0 to check the queue.
>>
>> Which is not cheap.

After bouncing that idea around with a fellow pgsql-hacker off-list, I
take that idea back.  It's a lot simpler and as cheap if not cheaper
to check getppid() == 1 or similar every Nth time through the busy
loop.

I heard another interesting idea -- you can use F_SETOWN + O_ASYNC to
ask for SIGIO to be delivered to you when the pipe is closed.
Unfortunately that'd require a different pipe for each backend so
wouldn't work for us.

-- 
Thomas Munro
http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Fix for documentation of Covering Indexes
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Boolean partitions syntax