Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Дата
Msg-id CA+TgmoYP7BnHXTEoJRUnOuie2J05Qo8ti5mnE2u-1c4Hk+8zJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-bugs
On Wed, May 25, 2022 at 7:45 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > Basically snapshots don't work anymore. If PROC_IN_SAFE_IC is set,
> > that backend is ignored for the horizon computation for snapshots /
> > on-access HOT pruning. Which means that rows that are visible to the
> > snapshot can be pruned away.
>
> I wondered if we could have different tuple horizons for HOT pruning
> than for vacuum, but looking at ComputeXidHorizons() and users of that,
> it looks complicated to adapt.
>
> Another possibility (than reverting the commit altogether) might be to
> disable HOT pruning while a process is operating on that relation with
> PROC_IN_SAFE_IC.  So CIC/RIC processes are still ignored for VACUUM,
> while not creating corrupted indexes.

I'm not sure that would be a win, because HOT pruning is great as long
as the tuples you're pruning are old enough. Also, it seems like it
would require complex new infrastructure that I think we should be
reluctant to invent in back branches.

It seems to me that we should just revert. As far as I can see, and
for sure I might be missing something, this is a classic case of an
idea that seemed good at the time but turns out not to work. When we
look at a recently HOT-updated tuple, we need to know whether the
original insertion happened before or after the index build. We can't
figure that out if we prune away the tuples that store the xmin values
that we need in order to figure that out. So it turns out we need
everyone to respect that snapshot after all. Bummer.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: operations i
Дата:
Сообщение: Re: How is this possible "publication does not exist"
Следующее
От: operations i
Дата:
Сообщение: Re: How is this possible "publication does not exist"