On Fri, Oct 27, 2017 at 3:13 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Oct 26, 2017 at 3:05 AM, Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> The largest obstacle to do that is that walreceiver is not >> utterly concerned to record internals. In other words, it doesn't >> know what a record is. Teaching that introduces much complexity >> and the complexity slows down the walreceiver. >> >> Addition to that, this "problem" occurs also on replication >> without a slot. The latest patch also help the case. > > That's why replication slots have been introduced to begin with. The > WAL receiver gives no guarantee that a segment will be retained or not > based on the beginning of a record. That's sad that the WAL receiver > does not track properly restart LSN and instead just uses the flush > LSN. I am beginning to think that a new message type used to report > the restart LSN when a replication slot is in use would just be a > better and more stable solution. I haven't looked at the > implementation details yet though.
Yeah, I am still on track with this idea. Splitting the flush LSN and the restart LSN properly can allow for better handling on clients. For now I am moving this patch to the next CF. -- Michael
