Re: SyncRepWaitForLSN waits for XLogFlush?

Hi Andres,

Thanks for your reply. If I understand you correctly, you're saying that
the walsender *waits* for xlogflush, but does not *cause* it. This means
that for a sync_commit=off transaction, the xlog records won't get shipped
out to standbys until the walwriter flushes in-memory xlog contents to disk.

And furthermore, am I correct in assuming that this behaviour is different
from the buffer manager and the slru which both *cause* xlog flush up to a
certain lsn before they proceed with flushing a page to disk?

The reason I'm asking this is that I'm working on modifying the transaction
manager for my thesis project, and the pg_walinspect test is failing when I
run make check-world. So, I'm just trying to understand things to identify
the cause of this issue.

Regards,
Tej

On Wed, 24 May 2023 at 17:33, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2023-05-24 10:53:51 -0400, Tejasvi Kashi wrote:
> > I was wondering if waiting for an LSN in SyncRepWaitForLSN ensures that
> the
> > XLOG has been flushed locally up to that location before the record is
> > shipped off to standbys?
>
> No, SyncRepWaitForLSN() doesn't directly ensure that. The callers have to
> (and
> do) call XLogFlush() separately. See e.g. the XLogFlush() call in
> RecordTransactionCommit().
>
> Note that calling SyncRepWaitForLSN() for an LSN that is not yet flushed
> would
> not lead for data to be prematurely sent out - walsender won't send data
> that
> hasn't yet been flushed. So a backend with such a spurious
> SyncRepWaitForLSN()
> would just wait until the LSN is actually flushed and *then* replicated.
>
> Any specific reason for that question?
>
> Greetings,
>
> Andres Freund
>