On Sun, Nov 27, 2022 at 6:07 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> On Friday, November 25, 2022 6:09 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Nov 25, 2022 at 8:16 AM houzj.fnst@fujitsu.com
> > <houzj.fnst@fujitsu.com> wrote:
> > >
> > > I think the reason is that we didn't filter the column when sending
> > > the old tuple in pgoutput. We thought that the old tuple won't include
> > > columns that not in RI, but it seems it will still be null values for
> > > such columns in the old tuple.
> > >
> >
> > Yes, that is correct. We do fill null values for non-replica identity columns in the
> > old tuple. See ExtractReplicaIdentity.
> >
> > > So, I think we'd better filter the column for old tuple as well.
> > >
> >
> > Your fix looks correct to me though I haven't tested it yet.
> >
> > Can we think of writing a test case using
> > pg_logical_slot_peek_binary_changes() similar to what we have in
> > 020_messages.pl?
>
> Yeah, I think it works.
>
> Besides, I find that we don't filter the column for DELETE as well because
> DELETE change only have old tuple. This looks like a similar problem as UPDATE,
> and I suppose we need to fix them all. Attach the new version patch which added
> the testcase as suggested and fix both DELETE and UPDATE cases.
>
LGTM, so pushed!
--
With Regards,
Amit Kapila.