Re: row filtering for logical replication

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.

After the commit 3696a600e2, the last patch does not apply cleanly. I'm
attaching another version to address the documentation issues.

--
Euler Taveira
EnterpriseDB: https://www.enterprisedb.com/