Thread: autovacuum worker started without a worker entry
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. 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>. Thanks, Luca
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@gmail.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.
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
On Thu, Aug 5, 2021 at 6:27 PM Vijaykumar Jain <vijaykumarjain.github@gmail.com> wrote: > postgres/varsup.c at master · postgres/postgres (github.com) > 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). Seem reasonable as explaination, even if sounds to me xidVacLimit is 65536. Thanks, Luca
Most probably, it runs a wraparound process, however, if you may see what command was invoked by that worker, it would be helpful.
Regards,
Ninad Shah
On Mon, 9 Aug 2021 at 01:48, Luca Ferrari <fluca1978@gmail.com> wrote:
On Thu, Aug 5, 2021 at 6:27 PM Vijaykumar Jain
<vijaykumarjain.github@gmail.com> wrote:
> postgres/varsup.c at master · postgres/postgres (github.com)
> 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).
Seem reasonable as explaination, even if sounds to me xidVacLimit is 65536.
Thanks,
Luca