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 →
-
Remove working test that was supposed to fail
- 2fd787d0aac1 19 (unreleased) landed
-
REPACK CONCURRENTLY: Don't use deferrable primary keys
- 832e220d99af 19 (unreleased) landed