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?
Re: SIGQUIT on archiver child processes maybe not such a hot idea? |
Список | 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 по дате отправления: