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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-08-21 16:04:14
Message-ID: 7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Emile Amewoto 2023-08-21 16:20:39 Re: Postgresql15 crash with :FATAL: could not open shared memory segment "/PostgreSQL.0000000": No such file or directory
Previous Message David G. Johnston 2023-08-21 15:52:34 Re: PGRES_EMPTY_QUERY from Postgre 14.3