On Tue, 02 Feb 2021 at 03:11, Euler Taveira <eu...@eulerto.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.
