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

From Alvaro Herrera
Subject Re: Column Filtering in Logical Replication
Date
Msg-id 202112161754.qzxph4hrdbfb@alvherre.pgsql
Whole thread Raw
In response to RE: Column Filtering in Logical Replication  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses RE: Column Filtering in Logical Replication  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Next
From: Alvaro Herrera
Date:
Subject: Re: Confused comment about drop replica identity index