Re: race condition when writing pg_control
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-06-08T06:26:56Z
Lists: pgsql-hackers
On Mon, Jun 08, 2020 at 03:25:31AM +0000, Bossart, Nathan wrote: > On 6/7/20, 7:50 PM, "Thomas Munro" <thomas.munro@gmail.com> wrote: >> I pushed 0001 and 0002, squashed into one commit. I'm not sure about >> 0003. If we're going to do that, wouldn't it be better to just >> acquire the lock in that one extra place in StartupXLOG(), rather than >> introducing the extra parameter? > > Thanks! The approach for 0003 was discussed a bit upthread [0]. I do > not have a strong opinion, but I lean towards just acquiring the lock. Fujii-san has provided an answer upthread, that can maybe translated as a +0.3~0.4: https://www.postgresql.org/message-id/fc796148-7d63-47bb-e91d-e09b62a502e9@oss.nttdata.com FWIW, I'd rather not take the lock as that's not necessary and just add the parameter if I were to do it. Now I would be fine as well to just take the lock if you decide that's more simple, as long as we add this new assertion as a safety net for future changes. -- Michael
Commits
-
Fix locking bugs that could corrupt pg_control.
- 09dc17486393 9.5.23 landed
- 644cac32a0bc 9.6.19 landed
- fd11b842eba9 10.14 landed
- 48eb6a3c895d 11.9 landed
- 72766ad6397a 12.4 landed
- acefa2cca6a2 13.0 landed
- 57cb8063089a 14.0 landed