Re: race condition when writing pg_control

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: race condition when writing pg_control
Date: 2020-06-08 06:26:56
Message-ID: 20200608062656.GC2589@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(dot)munro(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-06-08 06:29:14 Re: Bump default wal_level to logical
Previous Message Amit Kapila 2020-06-08 06:23:14 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions