Forgot attach patches in last letter. Attached here.
On 06.10.2026 13:34, Alena Rybakina wrote:
> 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.
>