Date: Thu, 16 Dec 2021 14:54:59 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: Rahila Syed <rahilasyed90@gmail.com>,
	Amit Kapila <amit.kapila16@gmail.com>,
	Tomas Vondra <tomas.vondra@enterprisedb.com>,
	Peter Smith <smithpb2250@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Column Filtering in Logical Replication
Message-ID: <202112161754.qzxph4hrdbfb@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <OS0PR01MB5716634DAF4C8020151D3FAA94779@OS0PR01MB5716.jpnprd01.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202112161754.qzxph4hrdbfb%40alvherre.pgsql>
Precedence: bulk

On 2021-Dec-16, houzj.fnst@fujitsu.com wrote:

> The patch ensures all columns of RT are in column list when CREATE/ALTER
> publication, but it seems doesn't prevent user from changing the replica
> identity or dropping the index used in replica identity. Do we also need to
> check those cases ?

Yes, we do.  As it happens, I spent a couple of hours yesterday writing
code for that, at least partially.  I haven't yet checked what happens
with cases like REPLICA NOTHING, or REPLICA INDEX <xyz> and then
dropping that index.

My initial ideas were a bit wrong BTW: I thought we should check the
combination of column lists in all publications (a bitwise-OR of column
bitmaps, so to speak).  But conceptually that's wrong: we need to check
the column list of each publication individually instead.  Otherwise, if
you wanted to hide a column from some publication but that column was
part of the replica identity, there'd be no way to identify the tuple in
the replica.  (Or, if the pgouput code disobeys the column list and
sends the replica identity even if it's not in the column list, then
you'd be potentially publishing data that you wanted to hide.)

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/