Re: Incorrect result of bitmap heap scan.

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)com>
Subject: Re: Incorrect result of bitmap heap scan.
Date: 2025-03-16 12:55:32
Message-ID: CALDaNm3_kv44y59YgAMaLSR7+DaaPo-sD2Q+FBxf=1cyk9uv-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 5 Mar 2025 at 16:43, Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> On Sun, 2 Mar 2025 at 01:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> > > Is everybody in agreement about committing and back patching this fix,
> > > which simply disables the optimization altogether?
> > > I myself don't see a better way, but thought I'd ask before proceeding
> > > with review and commit.
> >
> > If you don't see a clear path forward, then "disable" is the only
> > reasonable choice for the back branches. Maybe we'll find a fix
> > in future, but it seems unlikely that it'd be back-patchable.
>
> Agreed.
>
> Here's patch v5 for the master branch (now up to f4694e0f), with no
> interesting changes other than fixing apply conflicts caused by
> bfe56cdf.

I noticed that Andres's comment from [1] is not yet addressed,
changing the commitfest entry status to Waiting on Author, please
address the comment and change it back to Needs review.
[1] - https://www.postgresql.org/message-id/tf5pp2o2a5x5qjcseq354bd26ya4o7p2vjzm5z4w57ca3vy6bc@ep7enrljvdkr

Regards,
Vignesh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2025-03-16 12:58:17 Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Previous Message vignesh C 2025-03-16 12:53:31 Re: Forbid to DROP temp tables of other sessions