pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Cleaning up historical portability baggage
Date: Sat, 06 Aug 2022 19:52:28 -0400
Message-ID: <152116.1659829948@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKG+8KJFC5_+SZtUGbLgC1tm4zEE3aAUgTw_i+ZDNu-zzkw@mail.gmail.com>
References: <CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com>
	<CA+Tgmoazusui5EoU_7Z=AgwC5pTAqDndTa7d-owjvQwG3zoRhg@mail.gmail.com>
	<CA+hUKGLLJUMDgCzOK5K4NE6PpU87Ka7t7RQsZoZAZ_EKfL5L+A@mail.gmail.com>
	<CA+Tgmoaw6VBC9Xzr4vOaC0kc-94jb9nzH8MY38Gqn7=wy=i_3w@mail.gmail.com>
	<20220712173352.trdeq66asbv6vf2q@awork3.anarazel.de>
	<1662559.1657648462@sss.pgh.pa.us>
	<CA+hUKG+MOzmDkr27ceG8+uwgFxbJUUv699V3VP3DCioQigrf7A@mail.gmail.com>
	<1249825.1658622186@sss.pgh.pa.us>
	<CA+Tgmob_5AUNCzyFGJX6quYSnQnKCHW6DGGJa1noofJqSu+weg@mail.gmail.com>
	<3920417.1659710931@sss.pgh.pa.us>
	<CA+TgmoZriceWqD4WD2vzEgPPcbAoY6OPR0N9fQJ2ZPVdH_AzYQ@mail.gmail.com>
	<CA+hUKGKdmC4A7cJNNSmY6KTfUsnX0b2AnjJu52Wd3_uHO1bBpg@mail.gmail.com>
	<146576.1659825723@sss.pgh.pa.us>
	<CA+hUKG+8KJFC5_+SZtUGbLgC1tm4zEE3aAUgTw_i+ZDNu-zzkw@mail.gmail.com>

Thomas Munro <thomas.munro@gmail.com> writes:
> On Sun, Aug 7, 2022 at 10:42 AM Tom Lane <tgl@sss.pgh.pa.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





view thread (108+ messages)  latest in thread

Message-ID: <152116.1659829948@sss.pgh.pa.us>
Permalink:  ../152116.1659829948@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/152116.1659829948@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, robertmhaas@gmail.com, andrew@dunslane.net, andres@anarazel.de
  Subject: Re: Cleaning up historical portability baggage
  In-Reply-To: <152116.1659829948@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox