[HACKERS] Force 8.2 initdb to rename pg_database/pg_class minxid columns?

2006-11-02 Thread Tom Lane
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 (quotefrozen/) 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Force 8.2 initdb to rename pg_database/pg_class minxid columns?

2006-11-02 Thread Andrew Sullivan
On Thu, Nov 02, 2006 at 05:22:39PM -0500, Tom Lane wrote:
 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?

Given that the column name change entails backwards incompatibility
for many users, and the change no longer signifies an actual change
to underlying functionality, though, it seems worth the pain to me.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings