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 05AD5FE2-9A53-4D11-A3F8-3A83EBB0EB93@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>)
Responses Re: archive status ".ready" files may be created too early
List pgsql-hackers
On 8/18/21, 11:31 AM, "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org> wrote:
> I was wondering which would be better: before or after.
> XLogBackgroundFlush would do it anyway, so if you do it after then it's
> not clear to me that it'd do anything (I mean we should not do any new
> calls of NotifySegmentsReadyForArchive and just rely on the one in
> XLogBackgroundFlush -> XLogWrite).
>
> The advantage of doing NotifySegmentsReadyForArchive before
> XLogBackgroundFlush is that the files would be created sooner, so the
> archiver can be working in parallel while walwriter does its other
> thing; then we'd reach the NotifySegmentsReadyForArchive in
> XLogBackgroundFlush and it'd find nothing to do most of the time, which
> is just fine.

As long as XLogBackgroundFlush() found work to do, it would take care
of notifying, but I don't think we can depend on that.  However, since
we're primarily using the WAL writer to take care of the case when the
record has already been flushed, notifying beforehand seems fine to
me.  If XLogBackgroundFlush() does end up calling XLogWrite(), it'll
call it again, anyway.

In the attached patch, I modified XLogInsertRecord() to simply set the
latch if we detect that flushRecPtr has advanced.

Nathan


Attachment

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: Bruce Momjian
Date:
Subject: Re: strange case of "if ((a & b))"