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 по дате отправления: