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

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: archive status ".ready" files may be created too early
Дата
Msg-id B8282B41-7699-46D9-A517-B671A3266425@amazon.com
обсуждение исходный текст
Ответ на Re: archive status ".ready" files may be created too early  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On 8/30/21, 12:52 PM, "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org> wrote:
> On 2021-Aug-28, Andres Freund wrote:
>
>> While rebasing the aio patchset ontop of HEAD I noticed that this commit added
>> another atomic operation to XLogWrite() with archiving enabled. The WAL write
>> path is really quite hot, and at least some of the
>> NotifySegmentsReadyForArchive() calls are done while WALWriteLock is held.
>>
>> I think we should at least try to make the fast-path where no segment
>> boundaries were crossed use no atomic operations.
>
> I think the best way to achieve this is is to rely completely on
> walwriter doing the segment notification, so that the WAL write done by
> backend would only do a latch set.

+1.  If we do that, we may also want to move
NotifySegmentsReadyForArchive() to after the call to
XLogBackgroundFlush() in the WAL writer.

Nathan


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

Предыдущее
От: "alvherre@alvh.no-ip.org"
Дата:
Сообщение: Re: archive status ".ready" files may be created too early
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: dynamic result sets support in extended query protocol