From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <iwaasa(at)mxs(dot)nes(dot)nec(dot)co(dot)jp> |
Subject: | Re: Table-level log_autovacuum_min_duration |
Date: | 2015-03-23 13:25:20 |
Message-ID: | 20150323132520.GE3636@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | didier | 2015-03-23 13:54:11 | Re: PATCH: pgbench - merging transaction logs |
Previous Message | Вадим Горбачев | 2015-03-23 12:37:50 | Fwd: proposal GSoC 2015 task: Allow access to the database via HTTP |