Hello, I added this as Older Bugs in Open items. (I believe it's legit.) The latest patch still applies on the HEAD with some offsets.
At Tue, 23 Jan 2018 18:50:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20180123.185000.232069302.horiguchi.kyot...@lab.ntt.co.jp> > 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
