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: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Andres Freund <andres@anarazel.de>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2023-08-21T16:30:22Z
Lists: pgsql-bugs
Andrew Dunstan <andrew@dunslane.net> writes: > On 2023-08-21 Mo 08:33, Alvaro Herrera wrote: >> Hmm ... when exactly do these values get freed if no longer needed? Is >> the theory that leaking them is not relevant? > Not sure I understand "relevant" here. They don't get freed. There will > be at most one entry per row in pg_attribute where atthasmissing is > true. Yeah. My feeling is that as long as we don't make duplicate hashtable entries, there will never be so many entries that it'd be worth the cost and intellectual complexity of trying to clean them up. When and if that theory is disproven, we can think harder; but for now I think this approach is good enough. 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