Re: autovacuum worker started without a worker entry

From: Ninad Shah <nshah(dot)postgres(at)gmail(dot)com>
To: Luca Ferrari <fluca1978(at)gmail(dot)com>
Cc: Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: autovacuum worker started without a worker entry
Date: 2021-08-09 05:54:44
Message-ID: CAOFEiBe0Sdux9ipKKHOsR_0Ssv_TZWSLyoXSkgQoiNc6-KyZKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)gmail(dot)com> wrote:

> On Thu, Aug 5, 2021 at 6:27 PM Vijaykumar Jain
> <vijaykumarjain(dot)github(at)gmail(dot)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
>
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message A Z 2021-08-09 06:44:42 PostgreSQL general set of Questions.
Previous Message Masih Tavassoli 2021-08-09 05:17:22 Re: JWT decoder