Zeugswetter Andreas ADI SD wrote: > > > Seems like either we go back to ignoring non-connectable > > databases (with the risks that entails), or adopt some > > more-aggressive policy for launching autovacuums on them, or > > Um, I think we would want to still have the ability to not need to > frequently vacuum known frozen databases. > > Could we set datvacuumxid to frozenxid after freezing template0 > and making it non-connectable ? There was discussion about making > a non-connectable db connectable, one step would be to set datvacuumxid > to currentxid.
I tried to do this at some point, but it doesn't work. I think the problem appears when you create a new database after the template database has been frozen for a while. IIRC one of my proposed solutions was to force a vacuum of the new database right away, but that was shot down (for good reasons, I think). Another one was to mark the tables as frozen, which led to the suggestion of pg_class_nt, which eventually we shot down for other reasons. The last suggestion was to force the vacuuming of frozen databases, which is where we are now. I think the best solution for now is to force the vacuum of template databases. They are generally small, so this _shouldn't_ be an issue. (There _would_ be an issue if someone made big databases non-connectable for the purposes of avoiding vacuum; this was mentioned back then, but no one said that this would be an issue.) We can change that in 8.3 by reintroducing the concept of pg_class_nt and possibly pg_database_nt, which would allow us to really mark tables as completely frozen, and databases as not needing vacuum at all. > PS: I agree that the rename from datfrozenxid to datvacuumxid should be > undone Actually, the one that was renamed from datfrozenxid was datminxid, which is now being proposed to be removed. We are now changing the semantics of datvacuumxid to the old datfrozenxid. I also agree with the change (but keep in mind that I'm not affected as a beta tester, so my opinion may not count). PS -- yeah, I neglected the maintenance.sgml docs at the time :-( I noticed some days ago and I was going to submit appropriate changes. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster