the un-vacuumable table
От | Andrew Hammond |
---|---|
Тема | the un-vacuumable table |
Дата | |
Msg-id | 5a0a9d6f0806250040t3f3ca0fw9c1216e8744de563@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: the un-vacuumable table
|
Список | 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 по дате отправления: