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
