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 →
  1. Remove working test that was supposed to fail

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