Re: PANIC: failed to re-find parent key in "100924" for split pages 1606/1673
От | Simon Riggs |
---|---|
Тема | Re: PANIC: failed to re-find parent key in "100924" for split pages 1606/1673 |
Дата | |
Msg-id | 1231443486.18005.282.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: PANIC: failed to re-find parent key in "100924" for split pages 1606/1673 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PANIC: failed to re-find parent key in "100924" for split pages 1606/1673
|
Список | pgsql-bugs |
On Thu, 2009-01-08 at 14:19 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Thu, 2009-01-08 at 13:40 -0500, Tom Lane wrote: > >> No, that seems utterly unsafe to me. We'd have a corrupt index and > >> nothing to cause it to get repaired. > > > We do exactly this with GIN and GIST indexes currently. > > Which are not used in any system indexes. > > > I'd rather have a database that works, but has a corrupt index than one > > that won't come up at all. > > If the btree in question is a critical system index, your value of > "work" is going to be pretty damn small. Those are good points. So if its a system index we can throw a PANIC, else just LOG. Whilst a corrupt index is annoying in the extreme, a total server outage is not something we should allow. IMHO. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-bugs по дате отправления: