Re: race condition when writing pg_control

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: race condition when writing pg_control
Дата
Msg-id 20200608062656.GC2589@paquier.xyz
обсуждение исходный текст
Ответ на Re: race condition when writing pg_control  ("Bossart, Nathan" <bossartn@amazon.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Bump default wal_level to logical