Re: the un-vacuumable table

Andrew Hammond wrote:
> 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).

What kind of an index is it? Does "SELECT COUNT(*) from <table>" work?

> 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.

Yes, please take a filesystem-level backup right away to retain the 
evidence.

Could you connect to the hung backend with gdb and get a stacktrace?

-- 
   Heikki Lin****angas
   EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers