At Tue, 3 Sep 2019 02:42:19 +0000, "Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> wrote in <0A3221C70F24FB45833433255569204D1FD1609C@G01JPEXMBYT05> > From: Kyotaro Horiguchi [mailto:horikyota....@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
