Re: [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: michael.paquier@gmail.com
Cc: andres@anarazel.de, nag1010@gmail.com, jdnelson@dyn.com,
pgsql-hackers@postgresql.org
Date: 2017-09-06T08:36:02Z
Lists: pgsql-bugs, pgsql-hackers
Hi, At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in <CAB7nPqSPf0qkq=DhSO-tAM9++LSA2aEYSVJ3oY_EdUdb=jKi1w@mail.gmail.com> > On Mon, Sep 4, 2017 at 4:04 PM, Andres Freund <andres@anarazel.de> wrote: > > I've not read through the thread, but this seems like the wrong approach > > to me. The receiving side should use a correct value, instead of putting > > this complexity on the sender's side. > > Yes I agree with that. The current patch gives me a bad feeling to be > honest with the way it does things.. The problem is that the current ReadRecord needs the first one of a series of continuation records from the same source with the other part, the master in the case. A (or the) solution closed in the standby side is allowing to read a seris of continuation records from muliple sources. In this case the first part from the standby's pg_wal and the second part from the master via streaming replication. ReadRecord needed refactoring, (seems to me) breaking the concept of XLogReader plug-in system to accomplish this behavior. If it is preferable for you, I'll re-try that. Or hints for other solutions are also welcome. Is there any suggestions? regards, -- Kyotaro Horiguchi NTT Open Source Software Center
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