Re: pg_upgrade and wraparound - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_upgrade and wraparound
Date
Msg-id 7382.1528737252@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade and wraparound  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_upgrade and wraparound
List pgsql-general
Andres Freund <andres@anarazel.de> writes:
> I suspect the issue is that pg_resetwal does:
>     if (set_xid != 0)
>     {
>         ControlFile.checkPointCopy.nextXid = set_xid;

>         /*
>          * For the moment, just set oldestXid to a value that will force
>          * immediate autovacuum-for-wraparound.  It's not clear whether adding
>          * user control of this is useful, so let's just do something that's
>          * reasonably safe.  The magic constant here corresponds to the
>          * maximum allowed value of autovacuum_freeze_max_age.
>          */
>         ControlFile.checkPointCopy.oldestXid = set_xid - 2000000000;
>         if (ControlFile.checkPointCopy.oldestXid < FirstNormalTransactionId)
>             ControlFile.checkPointCopy.oldestXid += FirstNormalTransactionId;
>         ControlFile.checkPointCopy.oldestXidDB = InvalidOid;
>     }

> but we have codepath that doesn't check for oldestXidDB being
> InvalidOid.  Not great.

Hm, I think I'd define the problem as "pg_resetwal is violating the
expectation that oldestXidDB be valid".

However, this just explains the basically-cosmetic issue that the
complaint message mentions OID 0.  It doesn't really get us to the
answer to why Alexander is seeing a failure.  It might be useful
to see pg_controldata output for the old cluster, as well as
"select datname, datfrozenxid from pg_database" output from the
old cluster.

            regards, tom lane


pgsql-general by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_upgrade and wraparound
Next
From: Andres Freund
Date:
Subject: Re: pg_upgrade and wraparound