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 <and...@anarazel.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 >
