RE: Column Filtering in Logical Replication

Поиск
Список
Период
Сортировка
От houzj.fnst@fujitsu.com
Тема RE: Column Filtering in Logical Replication
Дата
Msg-id OS0PR01MB5716634DAF4C8020151D3FAA94779@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Column Filtering in Logical Replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Column Filtering in Logical Replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список 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 по дате отправления:

Предыдущее
От: Andrei Zubkov
Дата:
Сообщение: Re: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: [PATCH] sort leaf pages by ctid for gist indexes built using sorted method