Date: Thu, 20 Dec 2012 18:08:43 +0100 (CET)
From: Baptiste LHOSTE <blhoste@alaloop.com>
To: Kevin Grittner <kgrittn@mail.com>
Cc: pgsql-admin@postgresql.org, Sylvain CAILLET <scaillet@alaloop.com>
Message-ID: <74151148.2709769.1356023323230.JavaMail.root@alaloop.com>
In-Reply-To: <20121220164208.14700@gmx.com>
Subject: Re: Autovacuum issues with truncate and create index ...
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org


> Was the blocking you described occurring at the time you captured
> this? It doesn't seem to be showing any problem.

Yes indeed. We have noticed that any process seems to be in waiting situation but :
 - before the autovacuum process starts to work on the both kind of tables, truncate and index creation take less than 2 seconds
 - after the autovacuum process starts to work on the both kind of tables, truncate and index creation never end

We have to stop our process, then reset the autovacuum thresold for second kind of tables, then restart our process.

Is it possible that the fact that statistics of postgresql are not up-to-date could explain this behavior ?
Is it possible that the autovacuum process does not stop itself when we perform a truncate or a create index ?

> A minor release (where the version number doesn't change before the
> second dot) never requires a dump and restore. There is sometimes a
> need to do some cleanup work; for example, if a bug is fixed which
> could corrupt a particular type of index, the release notes may
> recommend rebuilding all indexes of that type to repair any damage
> which may have occurred before the bug was fixed.

As we mention in the previous mail, we can only upgrade to the 8.4.13 with Debian.


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin