Re: 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: stark@mit.edu
Cc: michael.paquier@gmail.com, jdnelson@dyn.com, pgsql-hackers@postgresql.org,
pgsql-bugs@postgresql.org
Date: 2018-01-23T08:05:11Z
Lists: pgsql-bugs, pgsql-hackers
Hello, At Fri, 19 Jan 2018 11:28:58 +0000, Greg Stark <stark@mit.edu> wrote in <CAM-w4HMU==SkHHzS6KDSrNiKU9vk2R4TG73M4FJzA-8Yui34+g@mail.gmail.com> > On 19 January 2017 at 09:37, Kyotaro HORIGUCHI > <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > > > > Though I haven't look closer to how a modification is splitted > > into WAL records. A tuple cannot be so long. As a simple test, I > > observed rechder->xl_tot_len at the end of XLogRecordAssemble > > inserting an about 400KB not-so-compressable string into a text > > column, but I saw a series of many records with shorter than > > several thousand bytes. > > I think the case to check is a commit record with many thousands of > subtransactions. I'm not sure you can fill a whole segment though. Thanks, potentially it can. 1 subtransaction adds 4 bytes so roughly 4.2M subtransactions will fill a segment but a transaction with 100000 subtrans didn't end returning a pile of many-many commans tags. ... Anyway, current point of the discussion is I think moved to the validity of taking a series of continuation records from different WAL sources, or acceptability of adding record-awareness to wal-receiver side. 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