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
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 |