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

From Tsunakawa, Takayuki
Subject RE: SIGQUIT on archiver child processes maybe not such a hot idea?
Date
Msg-id 0A3221C70F24FB45833433255569204D1FD1609C@G01JPEXMBYT05
Whole thread Raw
In response to Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Re: SIGQUIT on archiver child processes maybe not such a hot idea?
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_basebackup -F t fails when fsync spends more time thantcp_user_timeout
Next
From: Alexey Zagarin
Date:
Subject: Re: row filtering for logical replication