Re: [HACKERS] ERROR: infinite recursion in proc_exit
От | Kristofer Munn |
---|---|
Тема | Re: [HACKERS] ERROR: infinite recursion in proc_exit |
Дата | |
Msg-id | Pine.LNX.4.04.9911050129240.7118-100000@dec.munn.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] ERROR: infinite recursion in proc_exit (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] ERROR: infinite recursion in proc_exit
|
Список | pgsql-hackers |
> What Postgres version are you using? My apologies, should have included that with my original request: [PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66] > If you want to try to recover without doing an update, I think you'll > still need to do a pg_dump/destroydb/createdb/reload. It looks like > the indexes on pg_attribute have been corrupted, and there's not any > easier way to clean that up. (If it were a user table, you could just > drop and recreate the index, but don't try that on pg_attribute...) What are the ramifications of continuing with the corrupted indexes - undefined behavior? Filesystems have fsck to fix stuff - are there any tools on the docket to reconstruct the indexes or other recoverable things? These would be useful for systems where the database is 500+ Megs and takes quite awhile to reload. The application involved uses temp files (you see some sort of attribute failure in the VACUUM before everything goes haywire - perhaps unrelated) as well as transactions. I don't create or drop temp tables inside transactions to avoid the accompanying error messages. A database maintenance program runs nightly to cull old data from the database and then runs a vacuum. During that time, transactions continue unabated. - K Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * ICQ 352499 * www.munn.com
В списке pgsql-hackers по дате отправления: