Re: Race conditions with WAL sender PID lookups
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-05-18T02:25:55Z
Lists: 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
Commits
-
Fix locking in WAL receiver/sender shmem state structs
- 572d6ee6d41b 10.0 landed
-
pgstat: add WAL receiver status view & SRF
- b1a9bad9e744 9.6.0 cited