Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.



pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group