> On Sep 9, 2026, at 07:46, Fujii Masao <[email protected]> wrote: > > On Thu, Sep 3, 2026 at 7:39 PM Zsolt Parragi <[email protected]> > wrote: >> The attached patch fixes this to report NULL instead. > > Thanks for the patch! It looks good to me. So, barring any objections, > I'll commit it.
Also looks good to me.
>
> BTW, as a separate issue, is the following also problematic?
>
> WHEN command = 'REPACK' AND repack_index_relid = 0 THEN 'VACUUM FULL'
>
> REPACK ... USING INDEX ... should basically be displayed as "CLUSTER".
> But, if an index scan is not used (for example, when
> enable_indexscan is disabled), repack_index_relid can be 0, causing
> it to be displayed as "VACUUM FULL" unexpectedly. Thoughts?
>
Yes, this is true. Now heapam_relation_copy_for_cluster() only sets
PROGRESS_REPACK_INDEX_RELID if (OldIndex != NULL && !use_sort). So when
enable_indexscan is off, REPACK ... USING INDEX shows VACUUM FULL:
```
REPACK USING INDEX with enable_indexscan = off
SET
pg_sleep
----------
(1 row)
pid | relid | repack_command | repack_index_relid | compatibility_command |
phase
-------+--------+----------------+--------------------+-----------------------+------------------
57523 | j4_1.t | REPACK | 0 | VACUUM FULL |
rebuilding index
(1 row)
```
When enable_indexscan is on, it show CLUSTER:
```
REPACK USING INDEX with enable_indexscan = on
SET
pg_sleep
----------
(1 row)
pid | relid | repack_command | repack_index_relid | compatibility_command |
phase
-------+--------+----------------+--------------------+-----------------------+------------------
57591 | j4_1.t | REPACK | 16455 | CLUSTER |
rebuilding index
(1 row)
```
So, repack_index_relid now describes the actual scan method but not if index
ordering was requested. Maybe we should set PROGRESS_REPACK_INDEX_RELID in
cluster_rel() rather than heapam_relation_copy_for_cluster()? Like in the
attache diff.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
repack_index_relid-fix.diff
Description: Binary data
