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 <[email protected]> wrote: > > On Mon, Nov 24, 2025 at 4:18 PM Hannu Krosing <[email protected]> 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
