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
|
Список | 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 по дате отправления: