| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Hannu Krosing <hannuk(at)google(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipkumarb(at)google(dot)com> |
| Subject: | Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations |
| Date: | 2025-11-25 16:09:17 |
| Message-ID: | CAEze2Wic0fLb4xcO1VyBoq1Ae6SyZWG9+_jptkMU7f0eqi6ufQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 24 Nov 2025 at 23:09, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Mon, Nov 24, 2025 at 4:18 PM Hannu Krosing <hannuk(at)google(dot)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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-11-25 16:25:09 | Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent |
| Previous Message | Nikolay Samokhvalov | 2025-11-25 16:08:37 | Re: Missing wait events (gap analysis) |