Horton

Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-08-21T16:04:14Z
Lists: pgsql-bugs 
On 2023-08-21 Mo 08:33, Alvaro Herrera wrote:
> Hello,
>
> On 2023-Jul-12, Andrew Dunstan wrote:
>
>> +			entry = hash_search(missing_cache, &key, HASH_ENTER, &found);
>> +
>> +			if (!found)
>> +			{
>> +				/* cache miss, so we need a non-transient copy of the datum */
>> +				oldctx = MemoryContextSwitchTo(TopMemoryContext);
>> +				entry->value =
>> +					datumCopy(attrmiss->am_value, false, att->attlen);
>> +				MemoryContextSwitchTo(oldctx);
>> +			}
> 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. I originally suggested cleaning them up at transaction end, but 
there was an argument that that might not make them sufficiently 
long-lived, and I don't know of any time more coarse grained when we can 
conveniently clean them up.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Commits

  1. Cache by-reference missing values in a long lived context

  2. Fix order of operations in ExecEvalFieldStoreDeForm().