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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Luca Ferrari <fluca1978@gmail.com>, pgsql-bugs@postgresql.org, Peter Geoghegan <pg@bowt.ie>, pgsql-general <pgsql-general@postgresql.org>
Date: 2018-07-25T23:27:47Z
Lists: pgsql-bugs, pgsql-general
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


Commits

  1. Add table relcache invalidation to index builds.