Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
От | Thomas Munro |
---|---|
Тема | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) |
Дата | |
Msg-id | CA+hUKGLua5Pnx+rjjxg=3OPO4oOjtUPjeUYeZXh7TkH3gA7-Uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Jun 11, 2021 at 1:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <hlinnaka@iki.fi> writes: > > On 09/04/2021 07:01, Thomas Munro wrote: > >> This seems to work on Linux, macOS, FreeBSD and OpenBSD (and I assume > >> any other BSD). Can anyone tell me if it works on illumos, AIX or > >> HPUX, and if not, how to fix it or disable the feature gracefully? > >> For now the patch assumes that if you have SIGIO then you can do this; > >> perhaps it should also test for O_ASYNC? Perhaps HPUX has the signal > >> but requires a different incantation with I_SETSIG? > > I took a look on HPUX 10.20 (gaur's host): Thanks both for looking! Unfortunately I'll have to withdraw this patch in its current form. On closer inspection, only the last backend to start up and do F_SETOWN on the pipe receives the signal. We'd probably have to create a separate pipe for each backend, or something like that, which seems unwarranted so far. > * I found I_SETSIG, but ... > > $ grep -r SETSIG /usr/include > /usr/include/sys/stropts.h:#define I_SETSIG _IO('S', 9) /* request SIGPOLL signal on events */ > > stropts.h seems to be for a feature called "streams", which is > probably nonstandard enough that we don't want to deal with it. Agreed. It is technically POSIX, but optional and marked obsolescent. It's annoying to see that I_SETSIG did allow multiple processes to register to receive signals for the same event on the same underlying stream, unlike F_SETOWN. Oh well.
В списке pgsql-hackers по дате отправления: