Re: archive status ".ready" files may be created too early - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: archive status ".ready" files may be created too early
Date
Msg-id B8282B41-7699-46D9-A517-B671A3266425@amazon.com
Whole thread Raw
In response to Re: archive status ".ready" files may be created too early  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
List 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 by date:

Previous
From: "alvherre@alvh.no-ip.org"
Date:
Subject: Re: archive status ".ready" files may be created too early
Next
From: Peter Eisentraut
Date:
Subject: Re: dynamic result sets support in extended query protocol