REPACK CONCURRENTLY: Don't use deferrable primary keys
Álvaro Herrera <alvherre@kurilemu.de>
REPACK CONCURRENTLY: Don't use deferrable primary keys Similarly to logical replication, REPACK CONCURRENTLY needs to ability to reliably locate a tuple based on an identity. A replica identity index is okay. Primary keys normally also are, except when they are deferrable, because a tuple being modified might not yet be indexed, causing REPACK to fail. Change the REPACK CONCURRENTLY code to use GetRelationIdentityOrPK(), similar to what the logical replication code does. (Though we don't yet support locating tuples based on arbitrary indexes for replica identity FULL.) While at it, add a few more test cases for situations that aren't supported by REPACK, to improve coverage. Author: Chao Li <lic@highgo.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Antonin Houska <ah@cybertec.at> Reviewed-by: Yuchen Li <liyuchen_xyz@163.com> Discussion: https://postgr.es/m/10DD5E13-B45D-44F1-BE08-C63E00ABCAC0@gmail.com
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/commands/repack.c | modified | +7 −8 |
| src/test/regress/expected/cluster.out | modified | +50 −2 |
| src/test/regress/sql/cluster.sql | modified | +45 −2 |
Discussion
- repack: fix a bug to reject deferrable primary key fallback for concurrent mode 10 messages · 2026-04-17 → 2026-04-30