RE: Incorrect messages emitted from pgoutput when using column lists
От | houzj.fnst@fujitsu.com |
---|---|
Тема | RE: Incorrect messages emitted from pgoutput when using column lists |
Дата | |
Msg-id | OS0PR01MB571658F178388836D116217A94109@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Incorrect messages emitted from pgoutput when using column lists (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Incorrect messages emitted from pgoutput when using column lists
|
Список | pgsql-bugs |
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. Best regards, Hou zj
Вложения
В списке pgsql-bugs по дате отправления: