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

So what are the options for a clean fix ?
(the "Discussion:
https://postgr.es/m/17485-396609c6925b982d%40postgresql.org" link
gives 503 back so can't immediately check myself)

Do we also need to make sure that CIC will not miss hot-pruned tuples
? What is the exact mechanism for missing them ?

Or should we just try to have a separate frozen per-table Xmin to be
used by CIC ?

On Mon, Nov 24, 2025 at 11:09 PM 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.
>
> --
> Peter Geoghegan