Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY |
Дата | |
Msg-id | 202205251144.6t4urostzc3s@alvherre.pgsql обсуждение исходный текст |
Ответ на | 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 2022-May-24, Andres Freund wrote: > One might think that could be safe, after all the row is invisible to all > other backends. The problem is that the validation scan won't see *newer* rows > either, since they're not visible to the snapshot either. And if the new row > version is a HOT tuple, it won't have made an index entry on its own. Boom, > corruption. Whoa. My oversight here -- I failed to picture a HOT prune concurrently with CIC or RIC. > 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. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Postgres is bloatware by design: it was built to house PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
В списке pgsql-bugs по дате отправления: