Re: row filtering for logical replication

On Tue, 02 Feb 2021 at 03:11, Euler Taveira <euler(at)eulerto(dot)com> wrote:
> On Mon, Feb 1, 2021, at 6:11 AM, japin wrote:
>> Thanks for updating the patch. Here are some comments:
> Thanks for your review. I updated the documentation accordingly.
>
>> The documentation says:
>>
>> > Columns used in the <literal>WHERE</literal> clause must be part of the
>> > primary key or be covered by <literal>REPLICA IDENTITY</literal> otherwise
>> > <command>UPDATE</command> and <command>DELETE</command> operations will not
>> > be replicated.
> The UPDATE is an oversight from a previous version.
>
>>
>> Does the publication only load the REPLICA IDENTITY columns into oldtuple when we
>> execute DELETE? So the pgoutput_row_filter() cannot find non REPLICA IDENTITY
>> columns, which cause it return false, right? If that's right, the UPDATE might
>> not be limitation by REPLICA IDENTITY, because all columns are in newtuple,
>> isn't it?
> No. oldtuple could possibly be available for UPDATE and DELETE. However, row
> filter consider only one tuple for filtering. INSERT has only newtuple; row
> filter uses it. UPDATE has newtuple and optionally oldtuple (if it has PK or
> REPLICA IDENTITY); row filter uses newtuple. DELETE optionally has only
> oldtuple; row filter uses it (if available). Keep in mind, if the expression
> evaluates to NULL, it returns false and the row won't be replicated.
>

Thanks for your clarification.

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.