Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function
| От | Tom Lane |
|---|---|
| Тема | Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function |
| Дата | |
| Msg-id | 15803.1532561267@sss.pgh.pa.us обсуждение |
| Ответ на | 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>) |
| Ответы |
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 |
| Список | 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 по дате отправления: