the un-vacuumable table

From: "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: the un-vacuumable table
Date: 2008-06-25 07:40:35
Message-ID: 5a0a9d6f0806250040t3f3ca0fw9c1216e8744de563@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I found this error message in my log files repeatedly:

Error: failed to re-find parent key in "ledgerdetail_2008_03_idx2" for
deletion target page 64767

I though "hmm, that index looks broken. I'd better re-create it." So, I
dropped the index and then tried to create a new one to replace it. Which
completely locked up the backend that was running the CREATE TABLE. I ran
truss against the backend in question and it didn't register anything
(except signals 2 and 15 when I tried to cancel the query and kill the
backend respectively). I eventually had to restart the database to get the
CREATE INDEX process to go away (well, to release that big nasty lock).

I then tried to do a VACUUM FULL, but it didn't complete after more than 2
hours. I cancelled that and tried a CLUSTER in the hopes that it might work
a little faster. It did the exact same thing as the create index command:
completely locked up the backend.

So, I'm wondering what if anything I can do to get that table cleaned up.

Running 8.1.11 on FreeBSD 6.2.

Anyway, the current plan is to drop the table and reload it from backup. I'm
posting here in case there's interest in gathering some forensic data or a
clever suggetion about how I can recover this situation or even some ideas
about what's causing it.

Andrew

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2008-06-25 07:40:57 CVS Head psql bug?
Previous Message daveg 2008-06-25 03:57:19 Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout