Confused comment about drop replica identity index - Mailing list pgsql-hackers

From wangw.fnst@fujitsu.com
Subject Confused comment about drop replica identity index
Date
Msg-id OS3PR01MB6275464AD0A681A0793F56879E759@OS3PR01MB6275.jpnprd01.prod.outlook.com
Whole thread Raw
Responses Re: Confused comment about drop replica identity index
List pgsql-hackers
Hi hackers,

When I doing development based by PG, I found the following comment have a
little problem in file src/include/catalog/pg_class.h.

/*
 * an explicitly chosen candidate key's columns are used as replica identity.
 * Note this will still be set if the index has been dropped; in that case it
 * has the same meaning as 'd'.
 */
#define          REPLICA_IDENTITY_INDEX    'i'

The last sentence makes me a little confused :
[......in that case it as the same meaning as 'd'.]

Now, pg-doc didn't have a clear style to describe this.


But if I drop relation's replica identity index like the comment, the action
is not as same as default.

For example:
Execute the following SQL:
create table tbl (col1 int  primary key, col2 int not null);
create unique INDEX ON tbl(col2);
alter table tbl replica identity using INDEX tbl_col2_idx;
drop index tbl_col2_idx;
create publication pub for table tbl;
delete from tbl;

Actual result:
ERROR:  cannot delete from table "tbl" because it does not have a replica identity and publishes deletes
HINT:  To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE.

Expected result in comment:
DELETE 0


I found that in the function CheckCmdReplicaIdentity, the operation described
in the comment is not considered,
When relation's replica identity index is found to be InvalidOid, an error is
reported.

Are the comment here not accurate enough?
Or we need to adjust the code according to the comments?


Regards,
Wang wei



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Ashutosh Sharma
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity