Re: B-tree page deletion boundary cases

Поиск
Список
Период
Сортировка
От Nikhil Sontakke
Тема Re: B-tree page deletion boundary cases
Дата
Msg-id CANgU5ZePFi5ay=tiNA29woXi8GKDda8AOSL6VhS_3L3qX=2FZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: B-tree page deletion boundary cases  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
<div class="gmail_extra"> <br /><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
0.8ex;border-left:1pxsolid rgb(204,204,204);padding-left:1ex"><div class="im"> > Was wondering if there's a similar
bugwhich gets triggered while using<br /> > VACUUM FULL. See for instance this thread:<br /> ><br /> > <a
href="http://postgresql.1045698.n5.nabble.com/index-corruption-in-PG-8-3-13-td4257589.html"
target="_blank">http://postgresql.1045698.n5.nabble.com/index-corruption-in-PG-8-3-13-td4257589.html</a><br/> ><br
/>> This issue has been reported on-off from time to time and in most cases<br /> > VACUUM or VACUUM FULL appears
tobe involved. We have usually attributed it<br /> > to hardware issues and reindex has been recommended by default
asa<br /> > solution/work around..<br /><br /></div>I do not perceive much similarity.  The bug I've raised can
producewrong<br /> query results transiently.  It might permit injecting a tuple into the wrong<br /> spot in the tree,
yieldingpersistent wrong results.  It would not introduce<br /> tree-structural anomalies like sibling pointers
directedat zeroed pages or<br /> internal pages in an 1-level tree.  Given the symptoms you reported, I share<br />
Robert'ssuspicion of WAL replay in your scenario.<br /></blockquote></div><br />Thanks for taking the time to analyze
thisNoah.<br /><br />Regards,<br />Nikhils<br /></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: [PATCH] lock_timeout and common SIGALRM framework
Следующее
От: Sandro Santilli
Дата:
Сообщение: Re: Gsoc2012 idea, tablesample