the un-vacuumable table

------=_Part_2862_3279624.1214379635359
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_2862_3279624.1214379635359
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I found this error message in my log files repeatedly:<br><br>Error:
failed to re-find parent key in &quot;ledgerdetail_2008_03_idx2&quot; for
deletion target page 64767<br><br>I though &quot;hmm, that index looks
broken. I&#39;d better re-create it.&quot; 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&#39;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).<br>
<br>I then tried to do a VACUUM FULL, but it didn&#39;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.<br>
<br>So, I&#39;m wondering what if anything I can do to get that table
cleaned up.<br><br>Running 8.1.11 on FreeBSD 6.2.<br><br>Anyway, the
current plan is to drop the table and reload it from backup. I&#39;m
posting here in case there&#39;s interest in gathering some forensic data
or a clever suggetion about how I can recover this situation or even some
ideas about what&#39;s causing it.<br>
<br>Andrew<br>

------=_Part_2862_3279624.1214379635359--