Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option

Hi Jochen,

On Wed, Aug 19, 2026 at 4:33 PM Jochen Bandhauer <jb(at)jbitc(dot)de> wrote:

> Hello,
>
> on: PostgreSQL 19beta3 (development build (./configure --enable-debug
> --enable-cassert CFLAGS='-O0 -g3'))
> when using repack with the option CONCURRENTLY or when using USING INDEX
> the verbose output does not show the number of removable row versions.
> When using the command without these options the number of removable
> rows are shown.
>
> Complete Version: PostgreSQL 19beta3 on x86_64-pc-linux-gnu, compiled by
> gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), 64-bit
>
> Test Case:
>
> -- create table and data
> drop table if exists t;
> create table t (id bigint primary key, col1 bigint);
> create index i1 on t (col1);
> insert into t select generate_series(1, 100000);
>
> -- commands
> repack (verbose) t; -- found 0 removable => ok
> update t set col1=1;
> repack (verbose) t; -- found 100000 removable => ok
> update t set col1=1;
> repack (verbose,concurrently) t; -- found 0 removable => is this correct?
> update t set col1=1;
> repack (verbose) t using index i1; -- found 0 removable => is this
> correct?
> update t set col1=1;
> repack (verbose,concurrently) t using index i1; -- found 0 removable =>
> is this correct?
>
> -- output:
> mydb=# repack (verbose) t;
> INFO: repacking "public.t" in physical order
> INFO: "public.t": found 0 removable, 100000 nonremovable row versions
> in 443 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> CPU: user: 0.14 s, system: 0.00 s, elapsed: 0.14 s.
> REPACK
> mydb=# update t set col1=1;
> UPDATE 100000
> mydb=# repack (verbose) t;
> INFO: repacking "public.t" in physical order
> INFO: "public.t": found 100000 removable, 100000 nonremovable row
> versions in 984 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> CPU: user: 0.23 s, system: 0.00 s, elapsed: 0.23 s.
> REPACK
> mydb=# update t set col1=1;
> UPDATE 100000
> mydb=# repack (verbose,concurrently) t;
> INFO: repacking "public.t" in physical order
> INFO: "public.t": found 0 removable, 100000 nonremovable row versions
> in 1082 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> CPU: user: 0.37 s, system: 0.00 s, elapsed: 0.38 s.
> REPACK
> mydb=# update t set col1=1;
> UPDATE 100000
> mydb=# repack (verbose) t using index i1;
> INFO: repacking "public.t" using index scan on "i1"
> INFO: "public.t": found 0 removable, 100000 nonremovable row versions
> in 1082 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> CPU: user: 0.39 s, system: 0.00 s, elapsed: 0.40 s.
> REPACK
> mydb=# update t set col1=1;
> UPDATE 100000
> mydb=# repack (verbose,concurrently) t using index i1;
> INFO: repacking "public.t" using index scan on "i1"
> INFO: "public.t": found 0 removable, 100000 nonremovable row versions
> in 1082 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> CPU: user: 0.56 s, system: 0.01 s, elapsed: 0.59 s.
> REPACK
> mydb=#
>

Thanks for the super-clear reproducer; I can reproduce it on master as well.
The code in copy_table_data(), where VERBOSE bumps the log level to INFO
so the message becomes visible. The counts it prints (removable,
nonremovable,
and "dead row versions cannot be removed yet") are only ever computed in the
non-concurrent path: that path scans the old heap with SnapshotAny and
classifies
every tuple with HeapTupleSatisfiesVacuum(), which is what populates
tups_vacuumed
and tups_recently_dead. The concurrent path instead scans with a regular
MVCC
snapshot, so the scan itself returns only the rows visible to that
snapshot, and those
two counters stay at 0. So for the concurrent case it doesn't make sense to
report
removable/nonremovable counts, since they aren't tracked there. I think
it's more
useful to report the number of tuples copied into the new table. Small
patch below,
thoughts?

diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index edff54e734e..b780dbf2ff9 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -1438,16 +1438,23 @@ copy_table_data(Relation NewHeap, Relation OldHeap,
Relation OldIndex,
num_pages = RelationGetNumberOfBlocks(NewHeap);

/* Log what we did */
- ereport(elevel,
- (errmsg("\"%s.%s\": found %.0f removable, %.0f
nonremovable row versions in %u pages",
- nspname,
- RelationGetRelationName(OldHeap),
- tups_vacuumed, num_tuples,
- RelationGetNumberOfBlocks(OldHeap)),
- errdetail("%.0f dead row versions cannot be
removed yet.\n"
- "%s.",
- tups_recently_dead,
- pg_rusage_show(&ru0))));
+ if (!concurrent)
+ ereport(elevel,
+ (errmsg("\"%s.%s\": found %.0f removable,
%.0f nonremovable row versions in %u pages",
+ nspname,
+
RelationGetRelationName(OldHeap),
+ tups_vacuumed, num_tuples,
+
RelationGetNumberOfBlocks(OldHeap)),
+ errdetail("%.0f dead row versions cannot be
removed yet.\n"
+ "%s.",
+ tups_recently_dead,
+ pg_rusage_show(&ru0))));
+ else
+ ereport(elevel,
+ (errmsg("\"%s.%s\": copied %.0f row
versions in %u pages",
+ nspname,
RelationGetRelationName(OldHeap),
+ num_tuples, num_pages),
+ errdetail("%s.", pg_rusage_show(&ru0))));

/* Update pg_class to reflect the correct values of pages and
tuples. */
relRelation = table_open(RelationRelationId, RowExclusiveLock);

--
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/