Re: [HACKERS] ERROR: infinite recursion in proc_exit
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] ERROR: infinite recursion in proc_exit |
Дата | |
Msg-id | m11jinJ-0003kLC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] ERROR: infinite recursion in proc_exit (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Kristofer Munn <kmunn@munn.com> writes: > > [PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66] > > 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. I don't know if you could drop/rebuild an index on a system catalog while the database is online. But there was sometimes a utility called reindexdb. That used the bootstrap processing mode interface of the backend to drop and recreate all system catalog indices. I don't know who removed that and why, neither do I know if it would still be possible to drop and reindex through the bootstrap interface. Does someone remember why it's gone? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: