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

From houzj.fnst@fujitsu.com
Subject RE: Column Filtering in Logical Replication
Date
Msg-id OS0PR01MB5716634DAF4C8020151D3FAA94779@OS0PR01MB5716.jpnprd01.prod.outlook.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  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Tues, Dec 14, 2021 1:48 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Hmm, I messed up the patch file I sent.  Here's the complete patch.
> 

Hi,

I have a minor question about the replica identity check of this patch.

+check_publication_add_relation(Relation targetrel, Bitmapset *columns)
...
+            idattrs = RelationGetIndexAttrBitmap(targetrel,
+                                                 INDEX_ATTR_BITMAP_IDENTITY_KEY);
+            if (!bms_is_subset(idattrs, columns))
+                ereport(ERROR,
+                        errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
+                        errmsg("invalid column list for publishing relation \"%s\"",
+                               RelationGetRelationName(targetrel)),
+                        errdetail("All columns in REPLICA IDENTITY must be present in the column list."));
+

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 ?

Best regards,
Hou zj

pgsql-hackers by date:

Previous
From: Andrei Zubkov
Date:
Subject: Re: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index
Next
From: Andrey Borodin
Date:
Subject: Re: [PATCH] sort leaf pages by ctid for gist indexes built using sorted method