Re: SIGQUIT on archiver child processes maybe not such a hot idea? - Mailing list pgsql-hackers

At Tue, 3 Sep 2019 02:42:19 +0000, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> wrote in
<0A3221C70F24FB45833433255569204D1FD1609C@G01JPEXMBYT05>
> 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 the pid 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

I imagnined that we don't use system(3) at all. It would be
almost simplified version of system(3), but doesn't use
it.

> of the archiver when postmaster sends SIGQUIT to the child
> process group?

Mmmm.. That's bad. The commit 3ad0728c81 intends to send SIGQUIT
to the programs under system() for archiver process. I found the
discusion for the patch.

https://www.postgresql.org/message-id/flat/24849.1163826231%40sss.pgh.pa.us#c987fc18a4b9113c6276ae8b5d85abba

> Reimplementing system() seems pretty ugly, but maybe we have no choice.
> It strikes me that system() has a race condition as defined anyway,
> because if a signal arrives between blocking the handler and issuing the
> fork(), it'll disappear into the ether; and the same at the end of the
> routine.
..
>> Alternatively perhaps Postgres really ought to be using USR1/USR2 or other
>> signals that library routines won't think they have any business rearranging.
>
> The existing signal assignments were all picked for what seem to me
> to be good reasons; I'm disinclined to change them.  In any case, the
> important point here is that we'd really like an archive or recovery
> script, or for that matter any command executed via system() from a
> backend, to abort when the parent backend is SIGINT'd or SIGQUIT'd.

But now we know that sending it to grand-children is wrong in a
sense that that leads to left-alone unwanted core files. But the
behavior is already knwon at the time.

So, Now I know that we need to revert that in certain extent if
we want to stop the core-dumping behavior...


I'm inclined to think that we should just document that behavior..


> > # 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.

What??? Oops!!! I found it among "Whole Mssage", "Download mbox"
and "Resend email". Sorry for my slipperly eyes and thanks!

regrds.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center