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

Hi,

On 2018-06-28 08:02:10 -0700, Andres Freund wrote:
> I believe this happens because there's currently no relcache
> invalidation registered for the main relation, until *after* the index
> is built. Normally it'd be the CacheInvalidateRelcacheByTuple(tuple) in
> index_update_stats(), which is called at the bottom of index_build().
> But we never get there, because the earlier error. That's bad, because
> any relcache entry built *after* the CommandCounterIncrement() in
> CommandCounterIncrement() will now be outdated.
>
> In the olden days we most of the time didn't build a relcache entry
> until after the index was built - but plan_create_index_workers() now
> does. I'm suspect there's other ways to trigger that earlier, too.
>
> Putting in a CacheInvalidateRelcache(heapRelation); before the CCI in
> index_create() indeed makes the "borked relcache" problem go away.
>
>
> I wonder why we don't just generally trigger invalidations to an
> indexes' "owning" relation in CacheInvalidateHeapTuple()?
> else if (tupleRelId == IndexRelationId)
> {
> Form_pg_index indextup = (Form_pg_index) GETSTRUCT(tuple);
>
> /*
> * When a pg_index row is updated, we should send out a relcache inval
> * for the index relation. As above, we don't know the shared status
> * of the index, but in practice it doesn't matter since indexes of
> * shared catalogs can't have such updates.
> */
> relationId = indextup->indexrelid;
> databaseId = MyDatabaseId;
> }

Tom, do you have any comments about the above? The biggest argument
against hardcoding that a pg_index update also invalidates the
corresponding relation, is that there's a lot of other things that we
could handle similarly. But I don't think any of those are as important
to relcache entries...

Greetings,

Andres Freund