pg_stat_progress_cluster: do not default to CLUSTER

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: pg_stat_progress_cluster: do not default to CLUSTER
Date: 2026-09-03 10:38:44
Message-ID: CAN4CZFMzy2V_wvRCBW5K8=wVCk1-C7nq=8otXO=u+s_1KZHqyA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

Since ac58465e061, pg_stat_progress_cluster is not built on
pg_stat_get_progress_info() but on pg_stat_progress_repack, and maps
the new REPACK command name back onto the two names the view used to
report. The mapping is a CASE ending in an unconditional ELSE
'CLUSTER'.

pg_stat_get_progress_info() hands pid and datid to every caller, but
NULLs other parameters if the caller no has privileges of the role
running the command.

That includes both command and repack_index_relid used in that CASE,
and we can display a VACUUM (FULL) as CLUSTER because of this default
branch.

The attached patch fixes this to report NULL instead. I also attached
a (LLM generated) script that reproduces the issue.

Attachment Content-Type Size
J4-1.sql application/octet-stream 5.3 KB
0001-Don-t-report-CLUSTER-for-a-redacted-progress-row.patch application/octet-stream 2.8 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2026-09-03 10:44:00 Re: Logical replication can lose an update after concurrent index invalidation
Previous Message vignesh C 2026-09-03 10:38:38 Re: Logical replication row filter loses unchanged toasted columns