Re: Incorrect result of bitmap heap scan.
От | Andres Freund |
---|---|
Тема | Re: Incorrect result of bitmap heap scan. |
Дата | |
Msg-id | p7lxvkvziy7nfvivk4qtbca6l5rnvjbylt5xmqyzyldka7h4ii@m6nguoebcx3z обсуждение исходный текст |
Ответ на | Re: Incorrect result of bitmap heap scan. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On 2024-12-02 12:02:39 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > 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. > > Yup. I am saying that that qualifies as too-aggressive setting of the > all-visible bit. I'm not sure what rule we should adopt instead of > the current one, but I'd much rather slow down page freezing than > institute new page locking rules. How? This basically would mean we could never set all-visible if there is *any* concurrent scan on the current relation, because any concurrent scan could have an outdated view of all-visible. Afaict this isn't an issue of "too-aggressive setting of the all-visible bit", it's an issue of setting it at all. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: