> On Apr 20, 2026, at 22:52, Antonin Houska <[email protected]> wrote: > > Chao Li <[email protected]> wrote: > >> I am continuing to test REPACK, and I found another issue. >> >> In check_concurrent_repack_requirements(), if a table has no replica >> identity index, the code falls back to using the primary key if one exists. >> The problem is that a deferrable primary key cannot be used for this >> purpose. WAL generation does not consider a deferrable primary key to be a >> replica identity, so concurrent mode may not receive enough old tuple >> information to replay concurrent changes. > > Thanks for finding it, this is certainly a problem. > > I'm just thinking if it's worth a separate error message. > RelationGetIndexList() just ignores the deferrable PK > > if (replident == REPLICA_IDENTITY_DEFAULT && OidIsValid(pkeyIndex) && > !pkdeferrable) > relation->rd_replidindex = pkeyIndex; > > and if there's no other suitable index, the result is that there is no > identity index for the table. So the change attached here should be consistent > with this approach. > > -- > Antonin Houska > Web: https://www.cybertec-postgresql.com >
Hi Antonin, Thanks for your review. I guess you read the v1 patch. In v2, I have switched to use GetRelationIdentityOrPK() that Zhijie suggested, which has covered RelationGetIndexList() and all checks, so that code is simplified, and there is no longer a separate error message. As CFBot asked for, rebased to v3, nothing changed from v2. Can you please take a look at v3 again? BTW, could you please also take a look at [1] that is a comment-only change for repack. [1] https://postgr.es/m/[email protected] Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v3-0001-Reject-deferrable-primary-key-fallback-in-REPACK-.patch
Description: Binary data
