Message-ID: <ca91dc91-80ba-e954-213e-b4170a6160f5@enterprisedb.com>
Date: Mon, 31 Jan 2022 08:13:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.5.0
Subject: Re: Column Filtering in Logical Replication
Content-Language: en-US
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
 Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Amit Kapila <amit.kapila16@gmail.com>,
 "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
 Rahila Syed <rahilasyed90@gmail.com>, Peter Smith <smithpb2250@gmail.com>,
 pgsql-hackers@postgresql.org
References: <202201120041.p24wvsfcsope@alvherre.pgsql>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <202201120041.p24wvsfcsope@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/ca91dc91-80ba-e954-213e-b4170a6160f5%40enterprisedb.com>
Precedence: bulk

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.