On Wed, Jun 2, 2010 at 2:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I'm not sure that makes sense. I thought the point of separating the archive and streaming cases was that the same timeout wouldn't necessarily be correct for a 16MB WAL file as it would for a 16-byte WAL record you've just received. IOW, you might want max_archive_delay > max_streaming_delay. The original proposal also seems somewhat easier to understand, to me at least. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
