Thread: log_autovacuum
Could I suggest renaming log_autovacuum to log_autovacuum_min_duration? I found it confusing to when setting it to 0 *enabled* logging so I imagine others will be as well. Also it seems we may want to have other messages logged from autovacuum so it would be better to leave room for other log_autovacuum_* parameters and possibly a master "log_autovacuum" parameter. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote: > > Could I suggest renaming log_autovacuum to log_autovacuum_min_duration? Sure, whatever makes the most sense. In fact min_duration would be more consistent. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "El día que dejes de cambiar dejarás de vivir"
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Gregory Stark wrote:
>> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
> Sure, whatever makes the most sense. In fact min_duration would be more
> consistent.
I'm not sure I believe Greg's argument about needing more autovac
logging parameters, but since this one acts just like
log_min_duration_statement, I concur with renaming it.
regards, tom lane
Actually, we happen to be running into a situation here where we need more logging. We need to understand why autovacuum isn't considering logging this table: relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del| n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze -------+------------+------------+----------+--------------+----------+---------------+-----------+-----------+-----------+------------+------------+-------------+-------------------------------+--------------+-------------------------------16436 |public | stock | 0 | 0 | 45929274 | 45928278 | 0 | 12116286 | 0 | 25036190| 12723033 | | | | 2007-08-01 17:24:30.796874-07 It looks like there are some DEBUG3 messages which would be useful but I don't know of any convenient way to change the log level in autovacuum workers. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Fri, 2007-08-03 at 12:38 -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Gregory Stark wrote: > >> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration? > > > Sure, whatever makes the most sense. In fact min_duration would be more > > consistent. > > I'm not sure I believe Greg's argument about needing more autovac > logging parameters, but since this one acts just like > log_min_duration_statement, I concur with renaming it. log_min_duration_autovacuum makes the most sense in comparison, IMHO. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Fri, 2007-08-03 at 18:56 +0100, Gregory Stark wrote: > Actually, we happen to be running into a situation here where we need more > logging. We need to understand why autovacuum isn't considering logging this > table: > > relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del| n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze > -------+------------+------------+----------+--------------+----------+---------------+-----------+-----------+-----------+------------+------------+-------------+-------------------------------+--------------+------------------------------- > 16436 | public | stock | 0 | 0 | 45929274 | 45928278 | 0 | 12116286 | 0 | 25036190 | 12723033 | | | | 2007-08-01 17:24:30.796874-07 > > It looks like there are some DEBUG3 messages which would be useful but I don't > know of any convenient way to change the log level in autovacuum workers. It also appears that only a single autovacuum daemon active at any one time, which is also weird when we are supposed to have 3. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Aug 3, 2007, at 14:59 , Simon Riggs wrote: > On Fri, 2007-08-03 at 12:38 -0400, Tom Lane wrote: >> Alvaro Herrera <alvherre@commandprompt.com> writes: >>> Gregory Stark wrote: >>>> Could I suggest renaming log_autovacuum to >>>> log_autovacuum_min_duration? >> >>> Sure, whatever makes the most sense. In fact min_duration would >>> be more >>> consistent. >> >> I'm not sure I believe Greg's argument about needing more autovac >> logging parameters, but since this one acts just like >> log_min_duration_statement, I concur with renaming it. > log_min_duration_autovacuum > > makes the most sense in comparison, IMHO. True, but the log_min_duration_statement is kind of poorly named (as is log_min_error_statement). log_statement is the overall concept, min_duration and min_error further specialize the concept. log_statement_min_duration and log_statement_min_error would have been better, IMO. Question is whether it's better to move forward with consistent naming or improve naming when the chance arises. Michael Glaesemann grzm seespotcode net