Re: [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Andres Freund <andres@anarazel.de>, nag1010@gmail.com, jdnelson@dyn.com, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-10-26T18:13:55Z
Lists: pgsql-bugs, pgsql-hackers
On Thu, Oct 26, 2017 at 3:05 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@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. -- Michael
Commits
-
Fix scenario where streaming standby gets stuck at a continuation record.
- c06380e97692 9.4.18 landed
- 4ea8f7d4553e 9.5.13 landed
- 7b7521d65772 9.6.9 landed
- ca572db22f62 10.4 landed
- 066871980183 11.0 landed