From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com> |
Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: the un-vacuumable table |
Date: | 2008-06-25 09:58:04 |
Message-ID: | 486216AC.6040204@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Domingo Alvarez Duarte | 2008-06-25 12:12:00 | Extended security/restriction to any role with login access |
Previous Message | Russell Smith | 2008-06-25 09:00:21 | libpq does not manage SSL callbacks properly when other libraries are involved. |