| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: We shouldn't signal process groups with SIGQUIT |
| Date: | 2023-02-14 20:38:24 |
| Message-ID: | 1930610.1676407104@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> ISTM that signal_child() should downgrade SIGQUIT to SIGTERM when sending to
> the process group. That way we'd maintain the current behaviour for postgres
> itself, but stop core-dumping archive/restore scripts (as well as other
> subprocesses that e.g. trusted PLs might create).
Yeah, I had been thinking along the same lines. One issue
is that that means the backend itself will get SIGQUIT and SIGTERM
in close succession. We need to make sure that that won't cause
problems. It might be prudent to think about what order to send
the two signals in.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-02-14 20:47:12 | Re: We shouldn't signal process groups with SIGQUIT |
| Previous Message | Andres Freund | 2023-02-14 20:29:27 | We shouldn't signal process groups with SIGQUIT |