Re: repack: fix a bug to reject deferrable primary key fallback for concurrent mode

> On Apr 20, 2026, at 22:52, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>
> Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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 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/06F150E0-FDE9-4FC6-9EEF-79A759430471@gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/