Re: [WIP] Add relminxid column to pg_class

Tom Lane wrote:

> I'd argue that you should do nothing, ie, dropping a table should never
> affect datminxid.  The proper interpretation of the pg_database columns
> is that we guarantee that all XID's in the database are *at least* thus-
> and-so, not that the minimum is exact.

Ok, this new patch does this.  It allowed to simplify some code a bit,
and works wonderfully.

However I spotted another problem.  Suppose I initdb; then I use the
system for some 2 billion-minus-delta transactions.  At this point, I
create a new database using template0 as template.  When this is done,
the logic in createdb() puts the current TransactionId as
pg_database.datminxid and datvacuumxid, which is fine because we assume
that template0 is fully frozen and thus it doesn't need vacuuming right
away.

However, pg_class entries all contain values close to 500 (the Xid at
which the initial vacuum is run by initdb).  Thus if you vacuum only one
table, the cluster-wide limit will be set at that low value, and
suddenly the server will refuse to generate TransactionIds; the user
will be forced to start a standalone postgres to vacuum.

The solution seems to be to vacuum the whole database right after
cloning.  Or to forcibly set the pg_class value to the current
TransactionId, without vacuuming (which should be fine, because the
template database was frozen).

Thoughts?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.