Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2023-06-29T14:26:24Z
Lists: pgsql-bugs
Andrew Dunstan <andrew@dunslane.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
Commits
-
Cache by-reference missing values in a long lived context
- 2d13dab048a7 11.22 landed
- f938acd68b08 16.0 landed
- a68458108512 17.0 landed
- 75f323aa1c1e 15.5 landed
- 7f4515a58ebd 14.10 landed
- 1bb619d4d628 13.13 landed
- 01993ac748fd 12.17 landed
-
Fix order of operations in ExecEvalFieldStoreDeForm().
- d0ab203bc192 13.12 landed
- cc8cca3c2d60 15.4 landed
- 7f11b7a9cf18 11.21 landed
- 53b93e853ffe 12.16 landed
- 43af714defa0 16.0 landed
- 0789b82a9792 14.9 landed