| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cleaning up historical portability baggage |
| Date: | 2022-08-06 23:52:28 |
| Message-ID: | 152116.1659829948@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Sun, Aug 7, 2022 at 10:42 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * There is a race condition for recently-forked children: they might not
>> * have executed setsid() yet. So we signal the child directly as well as
>> * the group. We assume such a child will handle the signal before trying
>> * to spawn any grandchild processes. We also assume that signaling the
>> * child twice will not cause any problems.
> Oof. Fixed.
Hmm ... it seems like these other callers have the same race condition.
StatementTimeoutHandler and LockTimeoutHandler account for that
correctly by issuing two kill()s, so how is it OK for pg_signal_backend
and TerminateOtherDBBackends not to?
It would likely be a good idea for all these places to mention that
they're doing that to avoid a race condition, and cross-reference
signal_child for details. Or maybe we should promote signal_child
into a more widely used function?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-08-06 23:55:25 | Re: Cleaning up historical portability baggage |
| Previous Message | Andres Freund | 2022-08-06 23:52:16 | Re: failing to build preproc.c on solaris with sun studio |