Re: archive status ".ready" files may be created too early

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: archive status ".ready" files may be created too early
Дата
Msg-id 9FC83463-7422-46DF-AD50-53F16A551A3D@amazon.com
обсуждение исходный текст
Ответ на Re: archive status ".ready" files may be created too early  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 8/30/21, 3:40 PM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> On 8/30/21, 2:06 PM, "Andres Freund" <andres@anarazel.de> wrote:
>> Although, the more I think about, the more I am confused about the trailing
>>         if (XLogArchivingActive())
>>                 NotifySegmentsReadyForArchive(LogwrtResult.Flush);
>>
>> in XLogWrite(). Shouldn't that at the very least be inside the "If asked to
>> flush, do so" branch? Outside that and the finishing_seg branch
>> LogwrtResult.Flush won't have moved, right? So the call to
>> NotifySegmentsReadyForArchive() can't do anything, no?
>
> The registration logic looks like this:
>         1. Register boundary
>         2. Get flush location from shared memory
>         3. If flush location >= our just-registered boundary, nudge
>            the WAL writer to create .ready files if needed
>
> If we called NotifySegmentsReadyForArchive() before we updated the
> flush location in shared memory, we might skip nudging the WAL writer
> even though we should.

In the other thread [0], we're considering moving boundary
registration to before WALInsertLockRelease().  If I'm right that this
removes the race condition in question, we should be able to move the
call to NotifySegmentsReadyForArchive() at the end of XLogWrite() to
the if-asked-to-flush branch.

Nathan

[0] https://postgr.es/m/DE60B9AA-9670-47DA-9678-6C79BCD884E3%40amazon.com


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

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: archive status ".ready" files may be created too early
Следующее
От: Ranier Vilela
Дата:
Сообщение: Re: Avoid choose invalid number of partitions (src/backend/executor/nodeAgg.c)