Horton

Re: Should vacuum process config file reload more often

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Masahiko Sawada <sawada.mshk@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2023-04-05T19:58:28Z
Lists: pgsql-hackers 
On Wed, Apr 5, 2023 at 3:44 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> VacuumUpdateCosts() also calls AutoVacuumUpdateCostLimit(), so this will
> happen if a config reload is pending the next time vacuum_delay_point()
> is called (which is pretty often -- roughly once per block vacuumed but
> definitely more than once per table).
>
> Relevant code is at the top of vacuum_delay_point():
>
>     if (ConfigReloadPending && IsAutoVacuumWorkerProcess())
>     {
>         ConfigReloadPending = false;
>         ProcessConfigFile(PGC_SIGHUP);
>         VacuumUpdateCosts();
>     }

Yeah, that all makes sense, and I did see that logic, but I'm
struggling to reconcile it with what that comment says.

Maybe I'm just confused about what that comment is trying to explain.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Fix assertion failure in heap_vacuum_rel

  2. Fix vacuum_cost_delay check for balance calculation.

  3. Fix autovacuum cost debug logging

  4. Refresh cost-based delay params more frequently in autovacuum

  5. Separate vacuum cost variables from GUCs

  6. Make vacuum failsafe_active globally visible

  7. Don't balance vacuum cost delay when per-table settings are in effect