Re: autovacuum does not start in HEAD

ITAGAKI Takahiro wrote:
> I found that autovacuum launcher does not launch any workers in HEAD.
> 
> AFAICS, we track the time to be vaccumed of each database in the following way:
> 
> 1. In rebuild_database_list(), we initialize avl_dbase->adl_next_worker
>    with (current_time + autovacuum_naptime / nDBs).
> 2. In do_start_worker(), we skip database entries that adl_next_worker
>    is between current_time and current_time + autovacuum_naptime.
> 3. If there is no jobs in do_start_worker(), we call rebuild_database_list()
>    to rebuild database entries.
> 
> The point is we use the same range (current_time and current_time +
> autovacuum_naptime) at 1 and 2. We set adl_next_worker with values in the
> range, and drop all of them at 2 because their values are in the range.
> And if there is no database to vacuum, we re-initilaize database list at 3,
> then we repeat the cycle.
> 
> Or am I missing something?

Note that rebuild_database_list skips databases that don't have stat
entries.  Maybe that's what confusing your examination.  When the list
is empty, worker are launched only every naptime seconds; and then it'll
also pick only databases with stat entries.  All other databases will be
skipped until the max_freeze_age is reached.  Right after an initdb or a
WAL replay, all database stats are deleted.

The point of (1) is to spread the starting of workers in the
autovacuum_naptime interval.

The point of (2) is that we don't want to process a database that was
processed too recently (less than autovacuum_naptime seconds ago).  This
is useful in the cases where databases are dropped, so the launcher is
awakened earlier than what the schedule would say if the dropped
database were not in the list.  It is possible that I confused the
arithmetic in there (because TimestampDifference does not return
negative results so there may be strange corner cases), but the last
time I examined it it was correct.

The point of (3) is to cover the case where there were no databases
being previously autovacuumed and that may now need vacuuming (i.e. just
after a database got its stat entry).

The fact that some databases may not have stat entries tends to confuse
the logic, both in rebuild_database_list and do_start_worker.  If it's
not documented enough maybe it needs extra clarification in code
comments.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.