Re: [HACKERS] ERROR: infinite recursion in proc_exit
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] ERROR: infinite recursion in proc_exit |
Дата | |
Msg-id | 29498.941788898@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] ERROR: infinite recursion in proc_exit (Kristofer Munn <kmunn@munn.com>) |
Ответы |
Re: [HACKERS] ERROR: infinite recursion in proc_exit
Re: [HACKERS] ERROR: infinite recursion in proc_exit |
Список | pgsql-hackers |
Kristofer Munn <kmunn@munn.com> writes: >> 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] Hmm. If that trace is from 6.5 code, then postgres.c should certainly be calling proc_exit after the recv() fails. I wonder if proc_exit is returning because proc_exit_inprogress is nonzero? proc_exit's use of elog(ERROR) does look mighty bogus to me --- that path could possibly cause a recursion just like this, but how did the code get into it to begin with? But that's not very relevant to your real problem, which is that there must be something corrupted in pg_attribute's indexes. > What are the ramifications of continuing with the corrupted indexes - > undefined behavior? I wouldn't recommend it. > Filesystems have fsck to fix stuff - are there any > tools on the docket to reconstruct the indexes or other recoverable > things? I've thought for some time that vacuum ought to just rebuild the indexes from scratch. That'd provide a recovery path for this sort of problem, and I suspect it'd actually be faster than what vacuum does now. I'm not volunteering to make it happen, though. regards, tom lane
В списке pgsql-hackers по дате отправления: