Re: Column Filtering in Logical Replication - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Column Filtering in Logical Replication
Date
Msg-id a5e04445-85a0-ef43-5a02-996ae59f301d@enterprisedb.com
Whole thread Raw
In response to Re: Column Filtering in Logical Replication  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Column Filtering in Logical Replication
List pgsql-hackers
On 07.03.22 16:18, Tomas Vondra wrote:
> AFAICS these issues should be resolved by the adoption of the row-filter
> approach (i.e. it should fail the same way as for row filter).

The first two patches (additional testing for row filtering feature) 
look okay to me.

Attached is a fixup patch for your main feature patch (the third one).

It's a bit of code and documentation cleanup, but mainly I removed the 
term "column filter" from the patch.  Half the code was using "column 
list" or similar and half the code "column filter", which was confusing. 
  Also, there seemed to be a bit of copy-and-pasting from row-filter 
code going on, with some code comments not quite sensible, so I rewrote 
some of them.  Also some code used "rf" and "cf" symbols which were a 
bit hard to tell apart.  A few more letters can increase readability.

Note in publicationcmds.c OpenTableList() the wrong if condition was used.

I'm still confused about the intended replica identity handling.  This 
patch still checks whether the column list contains the replica identity 
at DDL time.  And then it also checks at execution time.  I thought the 
latest understanding was that the DDL-time checking would be removed.  I 
think it's basically useless now, since as the test cases show, you can 
subvert those checks by altering the replica identity later.
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error
Next
From: Peter Eisentraut
Date:
Subject: Re: Time to drop plpython2?