Re: [HACKERS] 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: jdnelson@dyn.com, pgsql-hackers@postgresql.org, pgsql-bugs@postgresql.org
Date: 2017-02-01T07:41:38Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- 0001-Fix-a-bug-of-physical-replication-slot.patch (text/x-patch)
Hello, I'll add the rebased version to the next CF. At Fri, 20 Jan 2017 11:07:29 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20170120.110729.107284864.horiguchi.kyotaro@lab.ntt.co.jp> > > > > - Delaying recycling a segment until the last partial record on it > > > > completes. This seems doable in page-wise (coarse resolution) > > > > but would cost additional reading of past xlog files (page > > > > header of past pages is required). > > > > > > Hm, yes. That looks like the least invasive way to go. At least that > > > looks more correct than the others. > > > > The attached patch does that. Usually it reads page headers only > > on segment boundaries, but once continuation record found (or > > failed to read the next page header, that is, the first record on > > the first page in the next segment has not been replicated), it > > becomes to happen on every page boundary until non-continuation > > page comes. > > > > I leave a debug info (at LOG level) in the attached file shown on > > every state change of keep pointer. At least for pgbench, the > > cost seems ignorable. > > I revised it. It became neater and less invasive. > > - Removed added keep from struct WalSnd. It is never referrenced > from other processes. It is static variable now. > > - Restore keepPtr from replication slot on starting. keepPtr is renamed to a more meaningful name restartLSN. > - Moved the main part to more appropriate position. - Removed the debug print code. 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