Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Autovacuum loose ends

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>,pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Autovacuum loose ends
Date: 2005-07-31 17:02:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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

Alvaro Herrera (<alvherre[a]>)
"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)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-07-31 17:51:33
Subject: pg_dumpall --clean versus roles and shared dependencies
Previous:From: Dave PageDate: 2005-07-31 16:11:36
Subject: Re: Remote administration functionality

pgsql-patches by date

Next:From: Tom LaneDate: 2005-07-31 19:15:35
Subject: Re: [HACKERS] Autovacuum loose ends
Previous:From: Sean BurlingtonDate: 2005-07-31 16:16:32
Subject: Re: BUG #1794: inheritance removes permissions from the parent

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group