Re: Corrupted btree index on HEAD because of covering indexes
От | Teodor Sigaev |
---|---|
Тема | Re: Corrupted btree index on HEAD because of covering indexes |
Дата | |
Msg-id | 2d0042ef-1c49-2f03-a6da-28dccdbaaccf@sigaev.ru обсуждение исходный текст |
Ответ на | Re: Corrupted btree index on HEAD because of covering indexes (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Corrupted btree index on HEAD because of covering indexes
|
Список | pgsql-hackers |
> heard of people using bt_index_parent_check() in production, but only > when they already knew that their database was corrupt, and wanted to > isolate the problem. I imagine that people that use > bt_index_parent_check() in production do so because they want as much > information as possible, and are willing to do whatever it takes to > get more information. That why I think we need improve amcheck - ideally, it should not miss any mistakes in tree structure. >> Agree, but at least this place needs a comment - why it's safe. > > Good idea. Could you write it? I'm afraid I can't give good explanation why we believe that nobody update this page ant it's high key while page is unlocked but pinned. > >>> I also think that we could have better conventional regression test >>> coverage here. >> >> Will try to invent not so large test.oif it means they may get a little extra > > Your smaller test takes about 350ms to run on a debug build on my > laptop, which seems worth it (honestly, this test should have been > there already). Maybe we can add it to the amcheck regression tests > instead, since those are run less often. This also allows us to add a > test case specifically as part of the amcheck enhancement, which makes > a bit more sense. Hm, it seems to me, that 350ms is short enough to place it in both core and amcheck test. I think, basic functionality should be covered by core tests as we test insert/create. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-hackers по дате отправления: