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