Thanks Michael for pinpointing the commit. Can I take it that this is a
confirmed bug? If so, how likely is it to be fixed in 9.5?
On 17:33, Tue, 13/09/2016 Michael Paquier <michael.paquier@gmail.com> wrote:
> On Fri, Sep 9, 2016 at 10:26 AM, <leohuanruan@gmail.com> wrote:
> > When inserting records within a subtransaction, not all inserts are
> reported
> > by pg_logical_slot_peek_changes(). With more than 4096 inserts, the
> output
> > is truncated to the nearest multiple of 4096.
> >
> > This occurs in 9.5.4, but not in 9.5.3.
>
> And the first commit to cause this regression is this one:
> commit: 8caf9fe62544b351d4f6219bf416f5ce08ef3c21
> author: Tom Lane <tgl@sss.pgh.pa.us>
> date: Thu, 30 Jun 2016 12:37:02 -0400
> Fix typo in ReorderBufferIterTXNInit().
>
> This looks like it would cause changes from subtransactions to be missed
> by the iterator being constructed, if those changes had been spilled to
> disk previously. This implies that large subtransactions might be lost
> (in whole or in part) by logical replication. Found and fixed by
> Petru-Florin Mihancea, per bug #14208.
>
> Report: <20160622144830.5791.22512@wrigleys.postgresql.org>
>
> 4096 matches the maximum number of changes that can be saved in memory
> from reorderbuffer.c. Andres?
> --
> Michael
>
