the un-vacuumable table - Mailing list pgsql-hackers

From Andrew Hammond
Subject the un-vacuumable table
Date
Msg-id 5a0a9d6f0806250040t3f3ca0fw9c1216e8744de563@mail.gmail.com
Whole thread Raw
Responses Re: the un-vacuumable table  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-hackers
I found this error message in my log files repeatedly:<br /><br />Error: failed to re-find parent key in
"ledgerdetail_2008_03_idx2"for deletion target page 64767<br /><br />I though "hmm, that index looks broken. I'd better
re-createit." So, I dropped the index and then tried to create a new one to replace it. Which completely locked up the
backendthat was running the CREATE TABLE. I ran truss against the backend in question and it didn't register anything
(exceptsignals 2 and 15 when I tried to cancel the query and kill the backend respectively). I eventually had to
restartthe database to get the CREATE INDEX process to go away (well, to release that big nasty lock).<br /><br />I
thentried to do a VACUUM FULL, but it didn't complete after more than 2 hours. I cancelled that and tried a CLUSTER in
thehopes that it might work a little faster. It did the exact same thing as the create index command: completely locked
upthe backend.<br /><br />So, I'm wondering what if anything I can do to get that table cleaned up.<br /><br />Running
8.1.11on FreeBSD 6.2.<br /><br />Anyway, the current plan is to drop the table and reload it from backup. I'm posting
herein case there's interest in gathering some forensic data or a clever suggetion about how I can recover this
situationor even some ideas about what's causing it.<br /><br />Andrew<br /> 

pgsql-hackers by date:

Previous
From: daveg
Date:
Subject: Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Next
From: Tatsuo Ishii
Date:
Subject: CVS Head psql bug?