I am attempting to dive into code using english, not c, if i am misguiding, pls ignore.
On Thu, 5 Aug 2021 at 11:38, Luca Ferrari <fluca1978@xxxxxxxxx> wrote:
Hi all,
I occasionally see the message "WARNING: autovacuum worker started
without a worker entry" in the logs.
>From what I can see here
<https://github.com/postgres/postgres/blob/master/src/backend/postmaster/autovacuum.c#L1678>,
the launcher forked a worker and in the meantime the launcher decided
the worker is no more useful. If that is right, I'm guessing why the
worker should not be useful anymore: since a single worker could work
on a table, the only reason I can find is that someone run manually
vacuum within that database/table.
I think this is around this block, where a worker is assigned some task to do.
so if there is nothing to vacuum, no dead tuples or etc, or dead tuples in tx,
it might not get assigned any work, and hence would exit.
Moreover, I've a question about emergency autovacuum (wraparound).
Since autovacuum workers are started by postmaster on a signal
received by the autovacuum launcher, and since with autovacuum = off
the latter is not running, how does the postmaster decide to start and
emergency autovacuum?
I only found what seems to me a normal autovacuum start at
<https://github.com/postgres/postgres/blob/master/src/backend/postmaster/postmaster.c#L5263>.
I might be wrong, I did not run a backtrace though :)
* Check to see if it's safe to assign another XID. This protects against
* catastrophic data loss due to XID wraparound. The basic rules are:
* If we're past xidVacLimit, start trying to force autovacuum cycles.
* If we're past xidWarnLimit, start issuing warnings.
* If we're past xidStopLimit, refuse to execute transactions, unless
* we are running in single-user mode (which gives an escape hatch
* to the DBA who somehow got past the earlier defenses).
-- * catastrophic data loss due to XID wraparound. The basic rules are:
* If we're past xidVacLimit, start trying to force autovacuum cycles.
* If we're past xidWarnLimit, start issuing warnings.
* If we're past xidStopLimit, refuse to execute transactions, unless
* we are running in single-user mode (which gives an escape hatch
* to the DBA who somehow got past the earlier defenses).
Thanks,
Vijay
Mumbai, India
