Re: Vacuum statistics - Mailing list pgsql-hackers

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