Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest
Date
Msg-id 1558.1251749840@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-committers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 1. Cluster is close to the stop limit.
> 2. Autovacuum runs, updates pg_database and advances oldestXid. Phew!
> 3. Crash.

> After recovery, oldestXid is reset to the old value, and you start
> getting warnings again. However, everything seems fine in pg_database,
> all the databases have been recently vacuumed. Does autovacuum ever run
> to fix that? ISTM it won't.

Autovacuum will certainly run, it's more a question of will it fix
oldestXid.  I think we could deal with this by having the just-added
function TransactionIdLimitIsValid() return false if the oldestXid is
far enough back to cause warnings.

(Probably that wasn't the best choice of name, since we now have some
cases where the XID limit data isn't really "invalid" but we want to
force an update anyway.  I'm inclined to rename it to something like
ForceTransactionIdLimitUpdate, with inversion of the result sense.)

            regards, tom lane

pgsql-committers by date:

Previous
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql: Change the autovacuum launcher to read pg_database directly,
Next
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql: Move processing of startup-packet switches and GUC settings into