Re: Incorrect result of bitmap heap scan.

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Incorrect result of bitmap heap scan.
Дата
Msg-id CAH2-WzmNuB-xmQ29=GfL0g9nXrdYoPZo3Zeqm0UTncCWJQmMvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incorrect result of bitmap heap scan.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Incorrect result of bitmap heap scan.
Список pgsql-hackers
On Mon, Dec 2, 2024 at 12:02 PM Tom Lane <tgl@sss.pgh.pa.us> 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.

Freezing a page, and setting a page all-visible are orthogonal.
Nothing has changed about when or how we set pages all-visible in a
long time -- VACUUM has always done that to the maximum extent that
its OldestXmin cutoff will allow. (The changes to freezing made
freezing work a little bit more like that, the general idea being to
batch-up work.)

--
Peter Geoghegan



В списке pgsql-hackers по дате отправления: