Re: BUG #17245: Index corruption involving deduplicated entries
От | Andres Freund |
---|---|
Тема | Re: BUG #17245: Index corruption involving deduplicated entries |
Дата | |
Msg-id | 20211030221824.xhzfhwveam7ymqha@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #17245: Index corruption involving deduplicated entries (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #17245: Index corruption involving deduplicated entries
|
Список | pgsql-bugs |
On 2021-10-30 15:11:18 -0700, Peter Geoghegan wrote: > On Sat, Oct 30, 2021 at 1:42 PM Andres Freund <andres@anarazel.de> wrote: > > I think it probably is worth adding an error check someplace that verifies > > that problems of this kind will be detected with, uh, less effort. > > The draft fix is something I wanted to get out quickly to signal that > the bug is definitely going to be fixed soon. I'll need to carefully > think about this some more on Monday, to make sure that it becomes > much harder to break in roughly the same way once again. Makes sense. > > ISTM that at least a basic version of this is worth doing as a check throwing > > an ERROR, rather than an assertion. It's hard to believe this'd be a > > significant portion of the cost of heap_index_delete_tuples(), and I think it > > would help catch problems a lot earlier. > > I like the idea of doing that, but only on master. Hm. I wonder if it's not actually good to do something like it in 14, given that we know of a path to have corrupted indexes out there. > Separately, we should add an assertion that catches cases where a TID > in the index points to an LP_REDIRECT line pointer, which does not > point to a heap tuple with storage. Is it actually guaranteed that that's impossible to happen and wasn't ever possible? It's not obvious to me that a LP_REDIRECT pointing to an LP_DEAD tuple would be a real problem. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: