]> git.ipfire.org Git - thirdparty/postgresql.git/commit
REPACK CONCURRENTLY: Don't use deferrable primary keys
authorÁlvaro Herrera <alvherre@kurilemu.de>
Mon, 27 Apr 2026 16:22:03 +0000 (18:22 +0200)
committerÁlvaro Herrera <alvherre@kurilemu.de>
Mon, 27 Apr 2026 16:22:03 +0000 (18:22 +0200)
commit832e220d99afa241d80cd3334eb78439719fe744
tree024ac5c94d03b96d9b69969c913910aa85b3f9c5
parent33db6c4baf17e0fdf2ac08f7d050155985c0d7e3
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
src/backend/commands/repack.c
src/test/regress/expected/cluster.out
src/test/regress/sql/cluster.sql