Force 8.2 initdb to rename pg_database/pg_class minxid columns?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Force 8.2 initdb to rename pg_database/pg_class minxid columns?
Date: 2006-11-02 22:22:39
Message-ID: 21857.1162506159@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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</>) transaction ID 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2006-11-02 22:27:04 bug in timestamp and out of range values
Previous Message mark 2006-11-02 22:20:22 Re: Design Considerations for New Authentication Methods