Re: autovacuum worker started without a worker entry

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(at)gmail(dot)com> 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.
>
> postgres/autovacuum.c at master · postgres/postgres (github.com)
<https://github.com/postgres/postgres/blob/master/src/backend/postmaster/autovacuum.c#L1330>
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
> >.
>
>
postgres/varsup.c at master · postgres/postgres (github.com)
<https://github.com/postgres/postgres/blob/master/src/backend/access/transam/varsup.c#L113>
I think, this block when it is about to assign the next xid, it does the
math, and triggers an autolauncher start.
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).

--
Thanks,
Vijay
Mumbai, India