Thread

1. CLUSTER progress: wrong index_rebuild_count for tables with TOAST

   Adam Lee <adam8157@gmail.com> — 2026-06-26T06:45:57Z

   Hi,
   
   When I run CLUSTER (or VACUUM FULL / REPACK) on a table that has a TOAST
   table, pg_stat_progress_cluster shows a wrong index_rebuild_count. During
   the heap scan the count is already equal to the number of indexes, but it
   should be 0 until the indexes are rebuilt at the end.
   
   A simple way to reproduce it. Run CLUSTER in one session, and query the
   view from another session at the same time:
   
   ```
   CREATE TABLE t (i int, x text);
   INSERT INTO t SELECT g, repeat(md5(g::text), 1000)
     FROM generate_series(1, 5) g;
   CREATE INDEX ON t (i);
   CLUSTER t USING t_i_idx;
   
   -- phase "seq scanning heap", index_rebuild_count = 2 (should be 0)
   ```
   
   The reason is that make_new_heap() creates the new TOAST table, and its
   TOAST index, before the heap is scanned. Building that index reports
   CREATE INDEX progress. CREATE INDEX and the cluster command use the same
   progress field for different things, so the cluster command then shows a
   CREATE INDEX value as its index_rebuild_count.
   
   The fix is to not report progress for the TOAST index build, because it
   is an internal index, not a user CREATE INDEX. The patch also adds an
   isolation test that pauses CLUSTER at the start of the heap scan and
   checks that index_rebuild_count is 0.
   
   -- 
   Adam
   

2. Re: CLUSTER progress: wrong index_rebuild_count for tables with TOAST

   Antonin Houska <ah@cybertec.at> — 2026-06-26T15:23:53Z

   Adam Lee <adam8157@gmail.com> wrote:
   
   > The reason is that make_new_heap() creates the new TOAST table, and its
   > TOAST index, before the heap is scanned. Building that index reports
   > CREATE INDEX progress. CREATE INDEX and the cluster command use the same
   > progress field for different things, so the cluster command then shows a
   > CREATE INDEX value as its index_rebuild_count.
   
   I'd prefer enhanced progress monitoring that I proposed earlier [1]. The patch
   needs more work, I'll try to submit it for the next development cycle.
   
   [1] https://www.postgresql.org/message-id/30939.1777888333%40localhost
   
   -- 
   Antonin Houska
   Web: https://www.cybertec-postgresql.com