On Tue, 11 Nov 2008 22:02:17 -0500 Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Ivan Sergio Borgonovo <mail@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
