Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function - Mailing list pgsql-bugs

From Tom Lane
Subject Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function
Date
Msg-id 15803.1532561267@sss.pgh.pa.us
Whole thread Raw
In response to Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function  (Andres Freund <andres@anarazel.de>)
Responses Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function
Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function
List pgsql-bugs
Andres Freund <andres@anarazel.de> writes:
> On 2018-06-28 08:02:10 -0700, Andres Freund wrote:
>> I wonder why we don't just generally trigger invalidations to an
>> indexes' "owning" relation in CacheInvalidateHeapTuple()?

> Tom, do you have any comments about the above?

It seems like an ugly and fragile hack, offhand.  I can see the point
about needing to recompute the owning relation's index list, but there's
no good reason why an update of a pg_index row ought to force that.
You're using that as a proxy for creation or deletion of an index, but
(at least in principle) pg_index rows might get updated for existing
indexes.

Also, it's not clear to me why the existing places that force relcache
inval on the owning table during index create/delete aren't sufficient
already.  I suppose it's probably a timing problem, but it's not clear
why hacking CacheInvalidateHeapTuple in this fashion fixes that, or why
we could expect it to stay fixed.

            regards, tom lane


pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function
Next
From: Peter Geoghegan
Date:
Subject: Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function