Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
От | Andrey Borodin |
---|---|
Тема | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY |
Дата | |
Msg-id | A5A99A74-268D-46E1-AD16-A880A9C55B0B@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
|
Список | pgsql-bugs |
> On 25 May 2022, at 00:01, Andres Freund <andres@anarazel.de> wrote: > >>> On 24 May 2022, at 23:15, Andres Freund <andres@anarazel.de> wrote: >>> >>> I suspect the problem might be related to pruning done during the validation >>> scan. Once PROC_IN_SAFE_IC is set, the backend itself will not preserve tids >>> its own snapshot might need. Which will wreak havoc during the validation >>> scan. >> >> I observe that removing PROC_IN_SAFE_IC for index_validate() fixes tests. >> But why it's not a problem for index_build() scan? > > I now suspect it's a problem for both, just more visible for index_validate(). No, I understood now. index_build() in CIC can be safely replaced by index_build_empty(). index_build() is only called because many AMs can make index more efficient than index_build_empty()+inserts. BTW for other indexes that are built just by inserts we can safely optimize CIC by calling index_build_empty() instead ofindex_build() in Phase 1. >> And I do not understand why it's a problem that tuple is pruned during the scan... How does this "wreak havoc" happen? > > Basically snapshots don't work anymore I got it! (almost) Thank you! Now I see why tests in 002_cic.pl did not catch that: there were no HOT updates. So, can we leave the feature enabled for all the process besides index validation? We don't seem to need a valid snapshotin CIC anywhere else. Or it's safer to revert whole commit? Thanks! Best regards, Andrey Borodin.
В списке pgsql-bugs по дате отправления: