At Fri, 19 Jan 2018 18:24:56 +0900, Michael Paquier <michael.paqu...@gmail.com> wrote in <20180119092456.ga1...@paquier.xyz> > On Fri, Jan 19, 2018 at 10:54:53AM +0900, Kyotaro HORIGUCHI wrote: > > On the other hand if one logical record must be read from single > > source, we need any means to deterrent wal-recycling on the > > primary side. Conducting that within the primary side is rejected > > by consensus. > > There is this approach of extending the message protocol as well so as > the primary can retain the segments it needs to keep around...
I haven't seen it in detail but it seems meaning that it is done by notifying something from the standby to the parimary not knowing what is a WAL record on the standby side. > > (There might be smarter way to do that, though.) To > > do that from the standby side, just retarding write feedbacks or > > this kind of special feedback would be needed. In any way it is > > necessary to introduce WAL-record awareness into WAL shipping > > process and it's seemingly large complexity. > > Coming to logical slots, don't you need to be aware of the beginning of > the record on the primary to perform correctly decoding of tuples > through time travel? If the record is present across segments, it seems I'm not sure what the time travel is, but the requried segments seems kept safely on logical replication since the publisher moves restart_lsn not based on finished commits LSN, but on the beginning LSN of running transactions. In other words, logical decoding doesn't need to track each record for the purpose of keeping segments since it already keeping track of the beginning of a transaction. Physical replication is totally unaware of a WAL record, it just copies blobs in a convenient unit and only cares LSN. But the ignorance seems required to keep performance. > to me that it matters. Andres knows the answer to that for sure, so I > would expect to be counter-argued in the next 12 hours or so. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
