RE: SIGQUIT on archiver child processes maybe not such a hot idea?

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: SIGQUIT on archiver child processes maybe not such a hot idea?
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FD1609C@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Thomas Munro <thomas.munro@gmail.com>)
Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
From: Kyotaro Horiguchi [mailto:horikyota.ntt@gmail.com]
> Since we are allowing OPs to use arbitrary command as
> archive_command, providing a replacement with non-standard signal
> handling for a specific command doesn't seem a general solution
> to me. Couldn't we have pg_system(a tentative name), which
> intercepts SIGQUIT then sends SIGINT to children? Might be need
> to resend SIGQUIT after some interval, though..

The same idea that you referred to as pg_system occurred to me, too.  But I wondered if the archiver process can get
thepid of its child (shell? archive_command?), while keeping the capabilities of system() (= the shell).  Even if we
fork()and then system(), doesn't the OS send SIGQUIT to any descendents of the archiver when postmaster sends SIGQUIT
tothe child process group?
 


> # Is there any means to view the whole of a thread from archive?
> # I'm a kind of reluctant to wander among messages like a rat in
> # a maze:p

You can see the whole thread by clicking the "Whole Thread" link.


Regards
Takayuki Tsunakawa




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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_basebackup -F t fails when fsync spends more time thantcp_user_timeout
Следующее
От: Alexey Zagarin
Дата:
Сообщение: Re: row filtering for logical replication