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

Re: pg_clog questions

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Benjamin Krajmalnik <kraj(at)illumen(dot)com>, pgsql-admin(at)postgresql(dot)org,"Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Subject: Re: pg_clog questions
Date: 2006-05-25 20:43:19
Message-ID: 20060525204319.GL13700@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-admin
Tom Lane wrote:
> "Benjamin Krajmalnik" <kraj(at)illumen(dot)com> writes:
> >>> While checking our server, I noticed quite a few files in the pg_clog
> >>> directory.
> >>> Is there a maintenance task which can be run to purge the files which
> >>> are no longer needed?
> 
> >> VACUUM.  If they're not disappearing, you aren't running an adequate
> >> vacuum regime --- missing out some databases, perhaps?
> 
> > I have autovacuum turned on with the default settings.
> 
> Hm.  I believe that autovac only does database-wide vacuums when it
> thinks they're necessary to prevent transaction wraparound failures.
> Which would mean that it'd let pg_clog grow to something on the order
> of half a gig before any truncation would happen.  That's probably
> insufficiently aggressive :-(
> 
> Alvaro, Matthew, any thoughts about improving that?

Hum, IIRC there is a test somewhere to check pg_database.datvacuumxid
and issue a database-wide vacuum if it gets too old, but the test uses
a-little-less-than-2-billion to fire :-(

This is the code:

        /*
         * We look for the database that most urgently needs a database-wide
         * vacuum.  We decide that a database-wide vacuum is needed 100000
         * transactions sooner than vacuum.c's vac_truncate_clog() would
         * decide to start giving warnings.  If any such db is found, we
         * ignore all other dbs.
         *
         * Unlike vacuum.c, we also look at vacuumxid.  This is so that
         * pg_clog can be kept trimmed to a reasonable size.
         */
        freeze_age = (int32) (nextXid - tmp->frozenxid);
        vacuum_age = (int32) (nextXid - tmp->vacuumxid);
        tmp->age = Max(freeze_age, vacuum_age);

        this_whole_db = (tmp->age >
                         (int32) ((MaxTransactionId >> 3) * 3 - 100000));

Maybe it was foolish to use such a large constant in the vacuumxid case
:-(

> It strikes me that Alvaro's work-in-progress on maintaining per-table
> xmin info would allow truncation of clog without actually insisting on
> a database-wide VACUUM, but that's not going to be any help for
> existing releases.

Yeah.  The patch is almost ready BTW and I was about to post it on
Saturday but I got distracted.  I have a problem with sinval messages
:-(  I'll post it later today.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-admin by date

Next:From: Jim NasbyDate: 2006-05-25 20:51:54
Subject: Re: Restore of pg_dump taking a long time...
Previous:From: Tom LaneDate: 2006-05-25 20:20:44
Subject: Re: pg_clog questions

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