| From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
|---|---|
| To: | Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: autovacuum worker started without a worker entry |
| Date: | 2021-08-08 20:17:39 |
| Message-ID: | CAKoxK+4mtH9PC36oHnkVJzyi8CdKAyD6Fqvt4H3Q4o13yxDQKw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masih Tavassoli | 2021-08-09 02:16:12 | JWT decoder |
| Previous Message | Luca Ferrari | 2021-08-08 20:09:56 | Re: pgcrypto - real life examples to encrypt / decrypt |