From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Incorrect result of bitmap heap scan. |
Date: | 2024-12-02 16:52:43 |
Message-ID: | fw54ktry2576xqvztx642ee6352rwc57y5hs6arcfjeowq6yon@3njdaxumsidi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-12-02 11:43:42 -0500, Tom Lane wrote:
> Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-12-02 16:56:16 | Re: CREATE SCHEMA ... CREATE DOMAIN support |
Previous Message | Andres Freund | 2024-12-02 16:46:50 | Re: Incorrect result of bitmap heap scan. |