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() |