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

  1. Fix scenario where streaming standby gets stuck at a continuation record.