Horton

Re: Should vacuum process config file reload more often

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, amit.kapila16@gmail.com
Date: 2023-04-03T19:08:37Z
Lists: pgsql-hackers 
Hi,

On 2023-04-03 14:43:14 -0400, Tom Lane wrote:
> Melanie Plageman <melanieplageman@gmail.com> writes:
> > v13 attached with requested updates.
> 
> I'm afraid I'd not been paying any attention to this discussion,
> but better late than never.  I'm okay with letting autovacuum
> processes reload config files more often than now.  However,
> I object to allowing ProcessConfigFile to be called from within
> commands in a normal user backend.  The existing semantics are
> that user backends respond to SIGHUP only at the start of processing
> a user command, and I'm uncomfortable with suddenly deciding that
> that can work differently if the command happens to be VACUUM.
> It seems unprincipled and perhaps actively unsafe.

I think it should be ok in commands like VACUUM that already internally start
their own transactions, and thus require to be run outside of a transaction
and at the toplevel. I share your concerns about allowing config reload in
arbitrary places. While we might want to go there, it would require a lot more
analysis.

Greetings,

Andres Freund

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