Re: Incorrect result of bitmap heap scan.
От | Andres Freund |
---|---|
Тема | Re: Incorrect result of bitmap heap scan. |
Дата | |
Msg-id | fw54ktry2576xqvztx642ee6352rwc57y5hs6arcfjeowq6yon@3njdaxumsidi обсуждение исходный текст |
Ответ на | Re: Incorrect result of bitmap heap scan. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Incorrect result of bitmap heap scan.
Re: Incorrect result of bitmap heap scan. |
Список | pgsql-hackers |
Hi, On 2024-12-02 11:43:42 -0500, Tom Lane wrote: > Peter Geoghegan <pg@bowt.ie> writes: > > This theory seems very believable. > > I'm not convinced. I think there are two assumptions underlying > bitmap scan: > > 1. Regardless of index contents, it's not okay for vacuum to remove > tuples that an open transaction could potentially see. So the heap > tuple will be there if we look, unless it was already dead (in which > case it could have been replaced, so we have to check visibility of > whatever we find). I think the problematic scenario involves tuples that *nobody* can see. During the bitmap index scan we don't know that though. Thus the tid gets inserted into the bitmap. Then, before we visit the heap, a concurrent vacuum removes the tuple from the indexes and then the heap and marks the page as all-visible, as the deleted row version has been removed. Then, during the bitmap heap scan, we do a VM lookup and see the page being all-visible and thus assume there's a visible tuple pointed to by the tid. No snapshot semantics protect against this, as the tuple is *not* visible to anyone. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: