From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
Cc: | Gunnar Morling <gunnar(dot)morling(at)googlemail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Incorrect messages emitted from pgoutput when using column lists |
Date: | 2022-11-25 10:08:42 |
Message-ID: | CAA4eK1KpMEQ4P7OVUeWO+ghWYAzmOuwaLvwfuxnKVsTZkVj7EQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Nov 25, 2022 at 8:16 AM houzj(dot)fnst(at)fujitsu(dot)com
<houzj(dot)fnst(at)fujitsu(dot)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?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Israel Barth Rubio | 2022-11-25 15:17:02 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Previous Message | bowenshi | 2022-11-25 09:56:37 | Re: BUG #17695: Failed Assert in logical replication snapbuild. |