Re: [HACKERS] Race conditions with WAL sender PID lookups - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Race conditions with WAL sender PID lookups
Date
Msg-id CAB7nPqT9AcRNewGwNGCdL5WBF2oc9sNjqrQcVM8q=4dZPYmjMw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Race conditions with WAL sender PID lookups  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, May 17, 2017 at 12:14 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, it's probably worth changing for consistency, but I'm not sure
> that it rises to the level of "a very bad idea".  It actually seems
> almost entirely harmless.  Spuriously setting the needreload flag on a
> just-deceased WAL sender will just result in some future WAL sender
> doing a bit of unnecessary work, but I don't think it breaks anything
> and the probability is vanishingly low.  The other change could result
> a bogus 0 PID in pg_stat_get_wal_senders output, but I bet you
> couldn't reproduce that more than once in a blue moon even with a test
> rig designed to provoke it, and if it does happen it isn't really
> anything more than a trivial annoyance.

Well, the window is very low, so only tests with precisely taken
breakpoints would show problems.

> So I'm in favor of committing this and maybe even back-patching it,
> but I also don't think it's a big deal.

Thanks. I would not mind if this is seen as a HEAD-only improvement.
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] fix hard-coded index in make_partition_op_expr
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Improvement in log message of logical replicationworker