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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Andres Freund <andres@anarazel.de>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-08-22T19:22:46Z
Lists: pgsql-bugs 
On 2023-08-21 Mo 12:30, Tom Lane wrote:
> 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.
>
> 			


Fix pushed to all relevant branches.


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().