SyncRepWaitForLSN waits for XLogFlush?

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

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@anarazel.de> wrote: