Michael Paquier wrote: > In AutoVacWorkerMain, I am reading the following: > > * Currently, we don't pay attention to postgresql.conf changes that > * happen during a single daemon iteration, so we can ignore SIGHUP. > */ > pqsignal(SIGHUP, SIG_IGN); > > So a worker does not see changes in postgresql.conf once it is run and > processes a database, no? The launcher does run ProcessConfigFile() > when SIGHUP shows up though.
Maybe this is something that we should change. For example, I wonder if this can also affect the cost-delay balancing heuristics; if two backends run the rebalance with different GUC settings because postgresql.conf changed in between each of them starting, would the settings bounce back and forth. I think it's worth reconsidering this. (Don't really remember in detail how it works; maybe it's fine now.) In any case, for log_autovacuum_min_duration it also seems worth keeping reasonably close track of GUC changes. I think reading them just before starting vacuum of a new relation should be enough. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
