On Fri, Jul 29, 2005 at 03:33:09PM -0400, Tom Lane wrote:
> It occurs to me that vacuuming to prevent XID wraparound is not the only
> reason to do DB-wide vacuums: we also need to keep
> pg_database.datvacuumxid from getting too old, else we will have
> problems with clog bloat. We may need to rethink the test used.
I was unable to come up with a reasonable test for this. How would we
determine what is "too old"? Of course, I could pick any number from
thin air, if that was what you were thinking. Going forward (8.2) I
think this should also be handled on a table per table basis, just like
the freeze Xid limit.
OTOH I just saw this comment in createdb():
/*
* Normally we mark the new database with the same datvacuumxid and
* datfrozenxid as the source. However, if the source is not allowing
* connections then we assume it is fully frozen, and we can set the
* current transaction ID as the xid limits. This avoids immediately
* starting to generate warnings after cloning template0.
*/
This means that if the user manages to unfreeze a database, disallow
connections, and later use it as a template, we could suffer Xid-
wraparound data loss in the new database. Should we rethink this?
Sadly, the only interface for disallowing connections is to manually
update pg_database, so it's impossible to raise a warning about it, or
something; and it's quite likely that people will disallow connections
without reading the proper documentation. (They do such things all the
time).
--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"La experiencia nos dice que el hombre peló millones de veces las patatas,
pero era forzoso admitir la posibilidad de que en un caso entre millones,
las patatas pelarían al hombre" (Ijon Tichy)