Alvaro Herrera wrote:
> 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.

BTW, I forgot to mention that I intend to apply this patch later today,
regardless of whatever solution we may decide for the problem below; we
can add it later, and it certainly is a corner case.

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

Another possibility is to have autovac vacuum all databases, including
those marked not connectable.  While this won't solve the problem for
those not running autovac, chances are that people doing so will be less
with each release.

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

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

Reply via email to