Hi, On 2021-10-11 12:27:44 -0400, Tom Lane wrote: > While that could be argued to be a bug, I share David's lack of interest in > fixing it, because I do not believe that there are any cases where a > function that accesses an index's subject table is really going to be > immutable.
> To prevent this access, we'd have to set pg_index.indisvalid false > initially and then update it to true after the index is built. > We do do that in CREATE INDEX CONCURRENTLY (so you can make this > example work by specifying CONCURRENTLY), but I'm unexcited about > creating bloat in pg_index for the standard case in order to support > a usage scenario that is going to cause you all sorts of other pain. > To paraphrase Henry Spencer: if you lie to the planner, it will get > its revenge. I agree that there's not much point in making this really "work", but perhaps we could try to generate a more useful error message, without incurring undue overhead? I think there've been a few reports of this over the years, including some internally to postgres, e.g. during catalog table index rebuilds. Perhaps we could set pg_index.indisvalid to false initially, and if opening an index where pg_index.indisvalid error out with a different error message if TransactionIdIsCurrentTransactionId(xmin). And then use an inplace update to set indisvalid to true, to avoid the bloat? Greetings, Andres Freund
