Re: check point segments leakage ?

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Gaetano Mendola <mendola(at)bigfoot(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: check point segments leakage ?
Date: 2004-07-21 14:26:35
Message-ID: 40FE7D1B.7050604@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gaetano Mendola wrote:
> Well, today I stop the pg_autovacuum and I did a vacuum full and I
> reindexed
> all big tables and other 500 MB were reclamed. Could be the pg_autovacuum
> running yesterday the responsible for these 500MB not reclamed during
> a vacuum full and reindex already performed yesterday ?

Probably not. Most of the time pg_autovacuum is just sleeping. If you
happened to fun a VACUUM FULL while pg_autovacuum was running a vacuum,
there might have been a conflict on the tabke pg_autovacuum was working
with at the time.

Also, are you sure that the space wasn't reclaimed yesterday after the
VACUUM FULL? It could be that your tables have grown 500M since then.
Remember, the minimum table size (the size after a VACUUM FULL) is not
necessarilly the optimial size. Postgresql will almost always need to
reallocate the space that was reclaimed by VACUUM FULL.

> I'm wandering if will be possible in the 7.5 start and stop the the
> autovacuum integrated in the backend.

Yes (at least the patch waiting to be applied to CVS HEAD does) in order
to stop autovacuum you will have to edit the autovac option in
postgresql.conf and HUP the postmaster.

Matthew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-07-21 14:39:47 Re: Patch for pg_dump: Multiple -t options and new -T option
Previous Message David F. Skoll 2004-07-21 14:22:25 Re: Patch for pg_dump: Multiple -t options and new -T