Re: Bug in Physical Replication Slots (at least 9.5)?

Hello,

At Fri, 19 Jan 2018 11:28:58 +0000, Greg Stark <stark(at)mit(dot)edu> wrote in <CAM-w4HMU==SkHHzS6KDSrNiKU9vk2R4TG73M4FJzA-8Yui34+g(at)mail(dot)gmail(dot)com>
> On 19 January 2017 at 09:37, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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