I wrote:
> I'm still inclined to apply the part of Simon's patch that adds a
> transmit timestamp to each SR send chunk. That would actually be
> completely unused by the slave given my proposal above, but I think that
> it is an important step to take to future-proof the SR protocol against
> possible changes in the slave-side timing logic.
On further contemplation, it seems like the protocol needs another field
besides that: each record should also carry a boolean indicating whether
walsender.c thinks it is currently "caught up", ie the record carries
all WAL data up to the current end of WAL. If the sender is not caught
up, then the receiver should apply max_archive_delay not
max_streaming_delay. In this way, WAL chunks that are a little bit
behind current time will be treated the same way whether they come
across the SR link or via the archive.
In conjunction with that, I think there's a logic bug in XLogSend;
it ought to be changed like so:
/* if we went beyond SendRqstPtr, back off */if (XLByteLT(SendRqstPtr, endptr))
+ { endptr = SendRqstPtr;
+ *caughtup = true;
+ }
In the current coding, the effect of not setting *caughtup here is just
that we uselessly call XLogSend an extra time for each transmission
(because the main loop won't ever delay immediately after a
transmission). But without this, we'd never send caughtup = true
to the slave.
regards, tom lane
