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.