Hi, On Fri, Sep 25, 2026 at 8:42 AM Sami Imseih <[email protected]> wrote: > > Here is a small patch to propagate track_cost_delay_timing to parallel > autovacuum workers. 1ff3180ca01 propagates the cost-based delay > parameters via PVSharedCostParams but left this one out, so a worker keeps > the value it inherited at parallel start, and workers will not report > sleep time if the GUC is turned on mid-flight. > > This only impacts delay reporting, but should be backpatched to 19 which > introduced parallel autovacuum.
Nice catch. Yes, when enabled, the parallel workers don't report their cost delay to the autovacuum worker (leader), so only the leader's cost delay is reported. Enabling it can have some overhead on certain platforms while getting the time, since the vacuum delay points are spread across the code. But when enabled, the workers not reporting their delay loses the benefit this GUC was added for, which is to reliably measure the impact of cost delay and cost limit changes on the vacuum duration. The user may have changed the cost limit and delay to slow things down or speed them up, and either way it is not good for the reported timing to miss the delay from the workers. So this is definitely a bug IMHO and an oversight in 1ff3180ca01. +1 to back-patch it to PG19. The v1 patch looks good to me with a few nits: 1/ At the end of parallel_vacuum_main(), do we need to gate the reporting of any remaining delay time on the accumulated delay time variable rather than on the GUC? Now that the GUC can change in a worker, if it is turned off after some delay time has accumulated since the last report, that remainder is never reported. It is a little less than a second at most, so I guess that is fine either way. 2/ Turning it on in the TAP test is probably not that costly on any of the CI or BF animals, since our tests don't vacuum anything large, so it shouldn't matter. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
