agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedrepack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
8+ messages / 4 participants
[nested] [flat]
* repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
@ 2026-08-19 11:03 Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Srinath Reddy Sadipiralla <srinath2133@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Jochen Bandhauer @ 2026-08-19 11:03 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
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
Jochen
--
Mit freundlichen Grüßen
Jochen Bandhauer
+49 (0)176 29390012
www.jbitc.de
Attachments:
[text/vcard] jb.vcf (202B, ../../5b73fd85-3066-4e41-b306-bfa8f893a239@jbitc.de/2-jb.vcf)
download | inline:
BEGIN:VCARD
VERSION:4.0
N:Bandhauer;Jochen;;;
FN:Jochen Bandhauer
EMAIL;PREF=1;TYPE=work:jb@jbitc.de
URL:https://www.jbitc.de
TEL;TYPE=work;VALUE=TEXT:+4917629390012
TZ:Europe/Berlin
END:VCARD
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
@ 2026-08-19 16:16 ` Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-08-25 19:57 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Srinath Reddy Sadipiralla @ 2026-08-19 16:16 UTC (permalink / raw)
To: Jochen Bandhauer <jb@jbitc.de>; +Cc: pgsql-bugs@lists.postgresql.org
Hi Jochen,
On Wed, Aug 19, 2026 at 4:33 PM Jochen Bandhauer <jb@jbitc.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/
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Srinath Reddy Sadipiralla <srinath2133@gmail.com>
@ 2026-08-25 19:57 ` Nathan Bossart <nathandbossart@gmail.com>
2026-08-25 21:00 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
0 siblings, 1 reply; 8+ messages in thread
From: Nathan Bossart @ 2026-08-25 19:57 UTC (permalink / raw)
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>; +Cc: Jochen Bandhauer <jb@jbitc.de>; pgsql-bugs@lists.postgresql.org
Does this one deserve a mention on the open items wiki [0]?
[0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
--
nathan
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-08-25 19:57 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Nathan Bossart <nathandbossart@gmail.com>
@ 2026-08-25 21:00 ` Jochen Bandhauer <jb@jbitc.de>
2026-08-26 00:44 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Fujii Masao <masao.fujii@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Jochen Bandhauer @ 2026-08-25 21:00 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; Srinath Reddy Sadipiralla <srinath2133@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
Am 25. August 2026 21:57:44 MESZ schrieb Nathan Bossart <nathandbossart@gmail.com>:
>Does this one deserve a mention on the open items wiki [0]?
>
>[0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>
>--
>nathan
I think yes. It's not critical to the functionality, but the verbose output is not correct.
Jochen
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-08-25 19:57 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Nathan Bossart <nathandbossart@gmail.com>
2026-08-25 21:00 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
@ 2026-08-26 00:44 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-26 12:56 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
0 siblings, 1 reply; 8+ messages in thread
From: Fujii Masao @ 2026-08-26 00:44 UTC (permalink / raw)
To: Jochen Bandhauer <jb@jbitc.de>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Srinath Reddy Sadipiralla <srinath2133@gmail.com>; pgsql-bugs@lists.postgresql.org
On Wed, Aug 26, 2026 at 6:00 AM Jochen Bandhauer <jb@jbitc.de> wrote:
>
> Am 25. August 2026 21:57:44 MESZ schrieb Nathan Bossart <nathandbossart@gmail.com>:
>>
>> Does this one deserve a mention on the open items wiki [0]?
>>
>> [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>>
>
> I think yes. It's not critical to the functionality, but the verbose output is not correct.
I agree that this should be fixed, but I wonder whether this is entirely
new in v19.
AFAICS, the same kind of misleading "removable" count can also occur with
CLUSTER USING INDEX in v18 and older releases, since the count depends
on the scan path. The CONCURRENTLY case is new, but the USING INDEX
case does not seem to be.
So I'm not sure this should be considered a v19 blocker. Perhaps
documenting this limitation for now would be sufficient?
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-08-25 19:57 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Nathan Bossart <nathandbossart@gmail.com>
2026-08-25 21:00 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-26 00:44 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Fujii Masao <masao.fujii@gmail.com>
@ 2026-08-26 12:56 ` Jochen Bandhauer <jb@jbitc.de>
2026-08-31 11:20 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
0 siblings, 1 reply; 8+ messages in thread
From: Jochen Bandhauer @ 2026-08-26 12:56 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Srinath Reddy Sadipiralla <srinath2133@gmail.com>; pgsql-bugs@lists.postgresql.org
On 26.08.2026 02:44, Fujii Masao wrote:
> On Wed, Aug 26, 2026 at 6:00 AM Jochen Bandhauer <jb@jbitc.de> wrote:
>> Am 25. August 2026 21:57:44 MESZ schrieb Nathan Bossart <nathandbossart@gmail.com>:
>>> Does this one deserve a mention on the open items wiki [0]?
>>>
>>> [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>>>
>> I think yes. It's not critical to the functionality, but the verbose output is not correct.
> I agree that this should be fixed, but I wonder whether this is entirely
> new in v19.
>
> AFAICS, the same kind of misleading "removable" count can also occur with
> CLUSTER USING INDEX in v18 and older releases, since the count depends
> on the scan path. The CONCURRENTLY case is new, but the USING INDEX
> case does not seem to be.
>
> So I'm not sure this should be considered a v19 blocker. Perhaps
> documenting this limitation for now would be sufficient?
>
> Regards,
>
I have taken a closer look at this today and I found that the
"removable" count was probably influenced by page pruning in my original
bug report. This can also be seen with the cluster command in v18. I
would propose to add these lines to the Notes section of the cluster and
repack command documentation:
The number of removable row versions shown in the verbose output should
not be considered a definitive measure of all dead tuples in the table.
It reflects the number of dead tuples encountered by the specific
scanning method (e.g., an index scan) that was used to rebuild the
table. In some cases, dead tuples may be physically removed from the
heap (pruned) before they are even encountered, further influencing this
count.
What do you think?
Jochen
--
Mit freundlichen Grüßen
Jochen Bandhauer
+49 (0)176 29390012
www.jbitc.de
Attachments:
[text/vcard] jb.vcf (202B, ../../c7f7da02-63e3-4a10-ab9a-25d9b82f1151@jbitc.de/2-jb.vcf)
download | inline:
BEGIN:VCARD
VERSION:4.0
N:Bandhauer;Jochen;;;
FN:Jochen Bandhauer
EMAIL;PREF=1;TYPE=work:jb@jbitc.de
URL:https://www.jbitc.de
TEL;TYPE=work;VALUE=TEXT:+4917629390012
TZ:Europe/Berlin
END:VCARD
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-08-25 19:57 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Nathan Bossart <nathandbossart@gmail.com>
2026-08-25 21:00 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-26 00:44 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Fujii Masao <masao.fujii@gmail.com>
2026-08-26 12:56 ` Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
@ 2026-08-31 11:20 ` Jochen Bandhauer <jb@jbitc.de>
0 siblings, 0 replies; 8+ messages in thread
From: Jochen Bandhauer @ 2026-08-31 11:20 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Srinath Reddy Sadipiralla <srinath2133@gmail.com>; pgsql-bugs@lists.postgresql.org
On 26.08.2026 14:56, Jochen Bandhauer wrote:
> On 26.08.2026 02:44, Fujii Masao wrote:
>> On Wed, Aug 26, 2026 at 6:00 AM Jochen Bandhauer <jb@jbitc.de> wrote:
>>> Am 25. August 2026 21:57:44 MESZ schrieb Nathan Bossart
>>> <nathandbossart@gmail.com>:
>>>> Does this one deserve a mention on the open items wiki [0]?
>>>>
>>>> [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>>>>
>>> I think yes. It's not critical to the functionality, but the verbose
>>> output is not correct.
>> I agree that this should be fixed, but I wonder whether this is entirely
>> new in v19.
>>
>> AFAICS, the same kind of misleading "removable" count can also occur
>> with
>> CLUSTER USING INDEX in v18 and older releases, since the count depends
>> on the scan path. The CONCURRENTLY case is new, but the USING INDEX
>> case does not seem to be.
>>
>> So I'm not sure this should be considered a v19 blocker. Perhaps
>> documenting this limitation for now would be sufficient?
>>
>> Regards,
>>
> I have taken a closer look at this today and I found that the
> "removable" count was probably influenced by page pruning in my
> original bug report. This can also be seen with the cluster command in
> v18. I would propose to add these lines to the Notes section of the
> cluster and repack command documentation:
>
> The number of removable row versions shown in the verbose output
> should not be considered a definitive measure of all dead tuples in
> the table. It reflects the number of dead tuples encountered by the
> specific scanning method (e.g., an index scan) that was used to
> rebuild the table. In some cases, dead tuples may be physically
> removed from the heap (pruned) before they are even encountered,
> further influencing this count.
>
> What do you think?
>
> Jochen
>
I created two patches for the doc update for REL_18_STABLE and master.
Regards
Jochen
--
Mit freundlichen Grüßen
Jochen Bandhauer
+49 (0)176 29390012
www.jbitc.de
From fccb8f2976c11308d2cdbd9e87bad6ac03c91893 Mon Sep 17 00:00:00 2001
From: Jochen Bandhauer <jb@jbitc.de>
Date: Mon, 31 Aug 2026 13:14:30 +0200
Subject: [PATCH v1] doc: add a note to cluster (verbose) regarding removable
row versions
---
doc/src/sgml/ref/cluster.sgml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml
index 8811f169ea0..784e4aff440 100644
--- a/doc/src/sgml/ref/cluster.sgml
+++ b/doc/src/sgml/ref/cluster.sgml
@@ -214,6 +214,15 @@ CLUSTER [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] [ <r
partitioned table cannot be executed inside a transaction block.
</para>
+ <para>
+ The number of removable row versions shown in the verbose output should not
+ be considered a definitive measure of all dead tuples in the table. It
+ reflects the number of dead tuples encountered by the specific scanning method
+ (e.g., an index scan) that was used to rebuild the table. In some cases, dead
+ tuples may be physically removed from the heap (pruned) before they are even
+ encountered, further influencing this count.
+ </para>
+
</refsect1>
<refsect1>
--
2.52.0
From 86355a121ffe39e05cda52e377965faa0de7054a Mon Sep 17 00:00:00 2001
From: Jochen Bandhauer <jb@jbitc.de>
Date: Mon, 31 Aug 2026 12:54:02 +0200
Subject: [PATCH v1] doc: add a note to repack (verbose) regarding removable
row versions
---
doc/src/sgml/ref/repack.sgml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/src/sgml/ref/repack.sgml b/doc/src/sgml/ref/repack.sgml
index 0cb72b6b289..eed85494f49 100644
--- a/doc/src/sgml/ref/repack.sgml
+++ b/doc/src/sgml/ref/repack.sgml
@@ -376,6 +376,15 @@ REPACK [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] USING
inside a transaction block.
</para>
+ <para>
+ The number of removable row versions shown in the verbose output should not
+ be considered a definitive measure of all dead tuples in the table. It
+ reflects the number of dead tuples encountered by the specific scanning method
+ (e.g., an index scan) that was used to rebuild the table. In some cases, dead
+ tuples may be physically removed from the heap (pruned) before they are even
+ encountered, further influencing this count.
+ </para>
+
</refsect1>
<refsect1>
--
2.52.0
Attachments:
[text/plain] v1-0001-doc-add-a-note-to-cluster-verbose_REL_18_STABLE.patch (1.2K, ../../2e7e3d82-9526-49c4-8ab0-15fd9c0c9696@jbitc.de/2-v1-0001-doc-add-a-note-to-cluster-verbose_REL_18_STABLE.patch)
download | inline diff:
From fccb8f2976c11308d2cdbd9e87bad6ac03c91893 Mon Sep 17 00:00:00 2001
From: Jochen Bandhauer <jb@jbitc.de>
Date: Mon, 31 Aug 2026 13:14:30 +0200
Subject: [PATCH v1] doc: add a note to cluster (verbose) regarding removable
row versions
---
doc/src/sgml/ref/cluster.sgml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml
index 8811f169ea0..784e4aff440 100644
--- a/doc/src/sgml/ref/cluster.sgml
+++ b/doc/src/sgml/ref/cluster.sgml
@@ -214,6 +214,15 @@ CLUSTER [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] [ <r
partitioned table cannot be executed inside a transaction block.
</para>
+ <para>
+ The number of removable row versions shown in the verbose output should not
+ be considered a definitive measure of all dead tuples in the table. It
+ reflects the number of dead tuples encountered by the specific scanning method
+ (e.g., an index scan) that was used to rebuild the table. In some cases, dead
+ tuples may be physically removed from the heap (pruned) before they are even
+ encountered, further influencing this count.
+ </para>
+
</refsect1>
<refsect1>
--
2.52.0
[text/plain] v1-0001-doc-add-a-note-to-repack-verbose_master.patch (1.1K, ../../2e7e3d82-9526-49c4-8ab0-15fd9c0c9696@jbitc.de/3-v1-0001-doc-add-a-note-to-repack-verbose_master.patch)
download | inline diff:
From 86355a121ffe39e05cda52e377965faa0de7054a Mon Sep 17 00:00:00 2001
From: Jochen Bandhauer <jb@jbitc.de>
Date: Mon, 31 Aug 2026 12:54:02 +0200
Subject: [PATCH v1] doc: add a note to repack (verbose) regarding removable
row versions
---
doc/src/sgml/ref/repack.sgml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/src/sgml/ref/repack.sgml b/doc/src/sgml/ref/repack.sgml
index 0cb72b6b289..eed85494f49 100644
--- a/doc/src/sgml/ref/repack.sgml
+++ b/doc/src/sgml/ref/repack.sgml
@@ -376,6 +376,15 @@ REPACK [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] USING
inside a transaction block.
</para>
+ <para>
+ The number of removable row versions shown in the verbose output should not
+ be considered a definitive measure of all dead tuples in the table. It
+ reflects the number of dead tuples encountered by the specific scanning method
+ (e.g., an index scan) that was used to rebuild the table. In some cases, dead
+ tuples may be physically removed from the heap (pruned) before they are even
+ encountered, further influencing this count.
+ </para>
+
</refsect1>
<refsect1>
--
2.52.0
[text/vcard] jb.vcf (202B, ../../2e7e3d82-9526-49c4-8ab0-15fd9c0c9696@jbitc.de/4-jb.vcf)
download | inline:
BEGIN:VCARD
VERSION:4.0
N:Bandhauer;Jochen;;;
FN:Jochen Bandhauer
EMAIL;PREF=1;TYPE=work:jb@jbitc.de
URL:https://www.jbitc.de
TEL;TYPE=work;VALUE=TEXT:+4917629390012
TZ:Europe/Berlin
END:VCARD
^ permalink raw reply [nested|flat] 8+ messages in thread
* Fwd: Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
@ 2026-08-26 07:18 Jochen Bandhauer <jb@jbitc.de>
0 siblings, 0 replies; 8+ messages in thread
From: Jochen Bandhauer @ 2026-08-26 07:18 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
On 26.08.2026 02:44, Fujii Masao wrote:
> On Wed, Aug 26, 2026 at 6:00 AM Jochen Bandhauer <jb@jbitc.de> wrote:
>> Am 25. August 2026 21:57:44 MESZ schrieb Nathan Bossart
>> <nathandbossart@gmail.com>:
>>> Does this one deserve a mention on the open items wiki [0]?
>>>
>>> [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>>>
>> I think yes. It's not critical to the functionality, but the verbose
>> output is not correct.
> I agree that this should be fixed, but I wonder whether this is entirely
> new in v19.
>
> AFAICS, the same kind of misleading "removable" count can also occur with
> CLUSTER USING INDEX in v18 and older releases, since the count depends
> on the scan path. The CONCURRENTLY case is new, but the USING INDEX
> case does not seem to be.
>
> So I'm not sure this should be considered a v19 blocker. Perhaps
> documenting this limitation for now would be sufficient?
>
> Regards,
>
All you said is correct, and it should not be considered a v19 blocker.
If the Open Items list only contains v19 blockers, then it shouldn't be
there (as opposed to what I said earlier).
Jochen
Attachments:
[text/vcard] jb.vcf (202B, ../../8c1acba6-7f7d-4daa-a43a-9bedaf078339@jbitc.de/2-jb.vcf)
download | inline:
BEGIN:VCARD
VERSION:4.0
N:Bandhauer;Jochen;;;
FN:Jochen Bandhauer
EMAIL;PREF=1;TYPE=work:jb@jbitc.de
URL:https://www.jbitc.de
TEL;TYPE=work;VALUE=TEXT:+4917629390012
TZ:Europe/Berlin
END:VCARD
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2026-08-31 11:20 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-08-19 11:03 repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
2026-08-19 16:16 ` Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-08-25 19:57 ` Nathan Bossart <nathandbossart@gmail.com>
2026-08-25 21:00 ` Jochen Bandhauer <jb@jbitc.de>
2026-08-26 00:44 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-26 12:56 ` Jochen Bandhauer <jb@jbitc.de>
2026-08-31 11:20 ` Jochen Bandhauer <jb@jbitc.de>
2026-08-26 07:18 Fwd: Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option Jochen Bandhauer <jb@jbitc.de>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox