Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations

From: Dilip Kumar <dilipbalaut(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 14:05:51
Message-ID: CAFiTN-uLJ5k2DBZDeJHUsDsHz48+Egs9bfZ-zZdN7C1MAjwPtw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 25, 2025 at 3:39 AM 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.

Interesting, so although it's not a problem for the vacuum itself,
vacuum would move the xmin forward and that will allow other backends
to hot prune the tuples from the table needed by the index building
snapshot.

--
Regards,
Dilip Kumar
Google

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2025-11-25 14:12:46 Re: Adding basic NUMA awareness
Previous Message Peter Eisentraut 2025-11-25 14:01:15 Re: SQL Property Graph Queries (SQL/PGQ)