Force 8.2 initdb to rename pg_database/pg_class minxid columns? - Mailing list pgsql-hackers

From Tom Lane
Subject Force 8.2 initdb to rename pg_database/pg_class minxid columns?
Date
Msg-id 21857.1162506159@sss.pgh.pa.us
Whole thread Raw
Responses Re: Force 8.2 initdb to rename pg_database/pg_class minxid columns?
List pgsql-hackers
Yesterday I wrote:
> * On successful completion, the cutoff XID is stored in
> pg_class.relvacuumxid, and pg_database.datvacuumxid is updated
> if appropriate.  (The minxid columns are now useless, but unless there
> is another reason to force initdb before 8.2, I'm inclined to leave them
> there and unused.  We can remove 'em in 8.3.)

After a closer look I am thinking that maybe we should go ahead and
replace relvacuumxid/relminxid and datvacuumxid/datminxid by single
columns named relfrozenxid and datfrozenxid respectively.  The reason
is that our documentation has for a long time recommended
SELECT datname, age(datfrozenxid) FROM pg_database;

as a good way to check for databases approaching wraparound.
(In fact it still does ... apparently Alvaro didn't bother to update 
maintenance.sgml when he redid that code.)

I don't know how many people might have such queries embedded in
maintenance scripts, but any who do will find their scripts broken by
8.2 as it now stands.  Which is a bit silly considering that the
proposed patch will be maintaining a column having exactly the
longstanding definition of datfrozenxid:
      All rows inserted by transaction IDs before this one have been      relabeled with a permanent (<quote>frozen</>)
transactionID in this      database.
 

I prefer to avoid forcing initdb in late beta, because it causes extra
work for our long-suffering beta testers, but at the moment I'm thinking
this is worth fixing now rather than later.  Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Design Considerations for New Authentication Methods
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Design Considerations for New Authentication Methods