From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Corruption with IMMUTABLE functions in index expression. |
Date: | 2021-10-11 18:25:35 |
Message-ID: | 20211011182535.pdwpfdex4rwojyyp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-10-11 18:26:24 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Previous Message | Peter Geoghegan | 2021-10-11 18:12:07 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |