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 17:19:08 |
Message-ID: | p7lxvkvziy7nfvivk4qtbca6l5rnvjbylt5xmqyzyldka7h4ii@m6nguoebcx3z |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-12-02 12:02:39 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2024-12-02 17:26:33 | Re: CREATE SCHEMA ... CREATE DOMAIN support |
Previous Message | Peter Geoghegan | 2024-12-02 17:15:19 | Re: Incorrect result of bitmap heap scan. |