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

From Peter Eisentraut
Subject Re: Column Filtering in Logical Replication
Date
Msg-id ca91dc91-80ba-e954-213e-b4170a6160f5@enterprisedb.com
Whole thread Raw
In response to Re: Column Filtering in Logical Replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Column Filtering in Logical Replication
List pgsql-hackers
On 12.01.22 01:41, Alvaro Herrera wrote:
> I discovered a big hole in this, which is that ALTER PUBLICATION SET
> (publish='insert,update') can add UPDATE publishing to a publication
> that was only publishing INSERTs.  It's easy to implement a fix: in
> AlterPublicationOptions, scan the list of tables and raise an error if
> any of them has a column list that doesn't include all the columns in
> the replica identity.

Right now, we are not checking the publication options and the replica 
identity combinations at all at DDL time.  This is only checked at 
execution time in CheckCmdReplicaIdentity().  So under that scheme I 
don't think the check you describe is actually necessary.  Let the user 
set whatever combination they want, and check at execution time if it's 
an UPDATE or DELETE command whether the replica identity is sufficient.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Greg Nancarrow
Date:
Subject: Re: row filtering for logical replication