Re: Vacuum statistics

Hi Vlada,

Thank you for testing v44 and for confirming that vacuum_interrupt_count
works correctly, including failures in parallel workers.

On 04.10.2026 17:07, Vlada Pogozhelskaya wrote:
> Hi Alena,
> Thank you for reworking vacuum_interrupt_count! I tested v44, and the
> counter now increases exactly once per failed VACUUM, including
> failures originating in a parallel worker. This part looks good to me.
>
> I found two other issues:
> 1. Parallel VACUUM appears to double-count worker resource usage.
> Worker index usage is reported separately, but is also included in the
> leader’s table-level usage. For example, with one parallel worker I
> observed:
> table.total_blks_read      = 729
> sum(index.total_blks_read) = 729
> database.db_blks_read      = 1459
>
> The corresponding serial VACUUM didn't show this duplication.
You are right: InstrAccumParallelQuery() adds the workers' buffer and
WAL usage to the leader's counters. The previous comment incorrectly
assumed that worker usage never reached those counters. Also, index
passes performed by the leader through the parallel vacuum path were not
included in the amount subtracted from the table report.
The fix accumulates the resource usage reported for each index in shared
memory, across both bulk-delete and cleanup passes. Before destroying
the parallel context, the leader collects these totals and subtracts
them from the table report. This covers WAL, buffer counters, and I/O
timing, including the case where parallel VACUUM is requested but no
workers are launched.
> 2. The reset functions retain the default EXECUTE privilege for PUBLIC.
> After granting a non-superuser USAGE on the extension schema, it could
> call all three reset functions and remove the accumulated statistics:
> vacuum_statistics_reset()
> extvac_reset_entry(oid, oid)
> extvac_reset_db_entry(oid)
>
> For comparison, pg_stat_reset* functions are restricted to POSTGRES,
> and pg_stat_statements explicitly revokes PUBLIC access to its reset
> function. Could the extension similarly restrict these functions?
PUBLIC privileges are now revoked for all three reset functions:
vacuum_statistics_reset(), extvac_reset_entry(oid, oid), and
extvac_reset_db_entry(oid). Access can still be granted explicitly to
other roles. I've also documented this restriction.

I've added the new TAP test that compares the table-plus-index totals
and the database aggregate against VACUUM VERBOSE's buffer and WAL
instrumentation. It covers serial VACUUM, parallel VACUUM, the parallel
path without available workers, and parallel index cleanup without bulk
deletion. It also checks that an ordinary role with schema USAGE cannot
call the reset functions, and that an explicit EXECUTE grant allows the
calls.

--
Regards,
Alena Rybakina
Yandex