| 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 |
| 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 |