> On Apr 20, 2026, at 22:52, Antonin Houska <ah@cybertec.at> wrote:
>
> Chao Li <li.evan.chao@gmail.com> 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
theprimary key if one exists. The problem is that a deferrable primary key cannot be used for this purpose. WAL
generationdoes not consider a deferrable primary key to be a replica identity, so concurrent mode may not receive
enoughold 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
Zhijiesuggested, which has covered RelationGetIndexList() and all checks, so that code is simplified, and there is no
longera 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/06F150E0-FDE9-4FC6-9EEF-79A759430471@gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
