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

Yuchen Li <liyuchen_xyz@163.com>

From: Yuchen Li <liyuchen_xyz@163.com>
To: Antonin Houska <ah@cybertec.at>, Chao Li <li.evan.chao@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2026-04-21T07:03:39Z
Lists: pgsql-hackers
On 4/21/2026 2:09 PM, Antonin Houska wrote:
> Chao Li <li.evan.chao@gmail.com> wrote:
>
>>> On Apr 20, 2026, at 22:52, Antonin Houska <ah@cybertec.at> wrote:
>>>
>>> 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.
>> 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.
> Yes, this looks like the best approach. Sorry for missing v2.
>
The patch looks good to me. Using GetRelationIdentityOrPK() makes the 
check match the intended replica identity semantics more closely, and 
the added regression coverage looks useful.

Regards,
Yuchen Li




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove working test that was supposed to fail

  2. REPACK CONCURRENTLY: Don't use deferrable primary keys