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
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