Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations
| От | Matthias van de Meent |
|---|---|
| Тема | Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations |
| Дата | |
| Msg-id | CAEze2Wic0fLb4xcO1VyBoq1Ae6SyZWG9+_jptkMU7f0eqi6ufQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations (Peter Geoghegan <pg@bowt.ie>) |
| Список | pgsql-hackers |
On Mon, 24 Nov 2025 at 23:09, Peter Geoghegan <pg@bowt.ie> wrote: > > On Mon, Nov 24, 2025 at 4:18 PM Hannu Krosing <hannuk@google.com> wrote: > > When VACUUM decides which rows are safe to freeze or permanently > > remove it currently ignores backends which have PROC_IN_VACUUM or > > PROC_IN_LOGICAL_DECODING bits set. > > > > This patch adds PROC_IN_SAFE_IC to this set, so backends running > > CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY and where the index > > is "simple" - i.e. not expression indexes or conditional indexes are > > involved - these would be ignored too. > > Are you aware of commit d9d076222f5b? It was subsequently reverted by > commit e28bb885 because it led to subtle data corruption. Indexes had > wrong contents due to an unforeseen interaction with pruning. Indeed, I don't think this is a correct change, given that these visibility horizons are calculated in every backend, and are also used for pruning. On-access pruning is one case where this is used and which would break - exactly the issue that caused d9d076222f5b to be reverted in e28bb885. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
В списке pgsql-hackers по дате отправления: