Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
От | Michael Paquier |
---|---|
Тема | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY |
Дата | |
Msg-id | YowwDSko1PkXIrHQ@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-bugs |
On Mon, May 23, 2022 at 10:07:44AM +0200, Alvaro Herrera wrote: > I think if this is a big enough deal (and I think it may be) then IMO we > should revert as you suggest, make an out-of-schedule release, and then > I can take some time to investigate in more depth and see if the feature > can be salvaged. > > OTOH if we think an out-of-schedule release is not warranted, then > reverting right now is not useful; we can make a decision about that > closer to the next minor release, once we've had time to see if the bug > can be fixed in some other way that doesn't break the whole feature. The annoying part is that this can cause silent corruptions for indexes created with REINDEX and CIC, so most users won't know about the failure until they see that their application is broken. And we are just talking about a btree index here, other index AMs may be similarly impacted. So that's rather bad IMHO :/ It seems to me that the problem is around the wait phase after the validation, where the computation of limitXmin coming from the snapshot used for the validation ignores now the impact of VACUUM, hence impacting the timing when the index can be safely used. It also looks like it is possible to build an isolation test, where we use a transaction with a snapshot older than the REINDEX to force it to wait in the first WaitForOlderSnapshots() call. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: