| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Luca Ferrari <fluca1978(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function |
| Date: | 2018-08-01 01:48:23 |
| Message-ID: | CAH2-WzmgqMxL5X0saGkAGYE2AU3xYgrtoAUmX_fwrEP1SaBzAg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-general |
On Mon, Jul 9, 2018 at 11:32 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I assume we'll have to backpatch this issue, so I think it'd probably a
> good idea to put a specific CacheInvalidateHeapTuple() in there
> explicitly in the back branches, and do the larger fix in 12. ISTM
> there's some risks that it'd cause issues.
What do you think of the attached?
The is a new CacheInvalidateRelcache() call, rather than a new call to
CacheInvalidateRelcacheByTuple(), but those two things are equivalent
(I assume that you actually meant to say
CacheInvalidateRelcacheByTuple(), not CacheInvalidateHeapTuple()).
Since nobody seems to be that excited about the
CacheInvalidateHeapTuple() idea, I haven't pursued it.
--
Peter Geoghegan
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-table-relcache-invalidation-to-index-builds.patch | application/octet-stream | 2.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-08-01 02:02:11 | Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function |
| Previous Message | Bruce Momjian | 2018-07-31 19:40:29 | Re: Found incorrect output in pg_lsclusters |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-08-01 02:02:11 | Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function |
| Previous Message | Tom Lane | 2018-07-31 22:33:45 | Re: How to prevent "no wait lock" after a connection drop |