| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: SIGQUIT on archiver child processes maybe not such a hot idea? |
| Date: | 2019-09-03 02:42:19 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FD1609C@G01JPEXMBYT05 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Kyotaro Horiguchi [mailto:horikyota(dot)ntt(at)gmail(dot)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 of the archiver when postmaster sends SIGQUIT to the 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Zagarin | 2019-09-03 03:15:44 | Re: row filtering for logical replication |
| Previous Message | Michael Paquier | 2019-09-03 01:58:18 | Re: pg_basebackup -F t fails when fsync spends more time than tcp_user_timeout |