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
-
Add table relcache invalidation to index builds.
- b3f919da0754 12.0 landed
- b9612e5cfab8 11.0 landed
- c83408aa71e0 10.5 landed
- 0a60a291c9a5 9.6.10 landed
- aca22574106e 9.5.14 landed
- 250528cec09f 9.4.19 landed
- 0229e087df2a 9.3.24 landed