| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
| Date: | 2023-06-29 14:26:24 |
| Message-ID: | 1509402.1688048784@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> After (not) sleeping on this overnight, and discussing it with a
> colleague this morning, here's a suggestion. We have a hash table, keyed
> by (tdtypeid, attnum) where we store a datumCopy'd version of the value.
> If it's present just return the value instead of getting it from the
> tupdesc. The hash table is blown away at the end of the transaction.
> Assuming that's workable I think it would not be a large patch.
That sounds possibly workable. I'm a bit concerned about added
overhead, and about whether the hashtable needs invalidation support.
It might be better to key it off (relfilenode, attnum).
> My colleague did ask if we had live reproducible case.
I have not attempted to build one, but it'd probably be fairly
easy to do if you turn on debug_discard_caches.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2023-06-29 16:24:32 | Re: pg_dump needs SELECT privileges on irrelevant extension table |
| Previous Message | Andrew Dunstan | 2023-06-29 13:56:39 | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |