Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() - Mailing list pgsql-bugs

From Andrew Dunstan
Subject Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Date
Msg-id 7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net
Whole thread Raw
In response to Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: PGRES_EMPTY_QUERY from Postgre 14.3
Next
From: Emile Amewoto
Date:
Subject: Re: Postgresql15 crash with :FATAL: could not open shared memory segment "/PostgreSQL.0000000": No such file or directory