On Tue, 11 Nov 2008 22:02:17 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> > Any suggestion about how to track down the problem?
>
> What you are describing sounds rather like a
> use-of-uninitialized-memory problem, wherein the behavior depends
> on what happened to be in that memory previously. If so, using a
> debug/cassert-enabled build of Postgres might help to make the
> behavior more reproducible.
>
> (Of course, if the result is that it's reproducibly fast, this
> doesn't get us much closer to solving the problem :-(. But it
> seems worth trying.)
There is no such a beast for Debian etch/sid.
Fortunately the re-indexing will happens very seldom and I can just
split the 2 parts so that I'll do my superstitious rituals before
re-indexing.
But it's like living with a ghost at home and at this moment it is
out of my reach compiling postgres.
I'm surprised I'm the only one experiencing this problem and I think
I'm using a quite popular set of packages: etch + postgresql
backport so I'm wondering if postgresql really deserve the blame or
it's something else.
But I can't think of any "strange" behaviour on my part that could
justify what's happening.
There are times (seldom actually) when the index get created in
around 6 minutes and times it takes forever even when the box is not
under load. Re-indexing with gist always succede in around 2min.
I even stopped the server and reload everything from backup.
During restore index creation happens in reasonable time.
Restore didn't report any error, but the behaviour is still there.
So maybe this stuff is triggered by some combination of the
postgresql configuration.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it