Re: repack: fix a bug to reject deferrable primary key fallback for concurrent mode
Antonin Houska <ah@cybertec.at>
From: Antonin Houska <ah@cybertec.at>
To: 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-21T06:09:42Z
Lists: pgsql-hackers
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. -- Antonin Houska Web: https://www.cybertec-postgresql.com
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