Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qYWxv-001zmz-Bj for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Aug 2023 19:22:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qYWxu-004Lfv-1u for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Aug 2023 19:22:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qYWxt-004Lfe-Oz for pgsql-bugs@lists.postgresql.org; Tue, 22 Aug 2023 19:22:57 +0000 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qYWxp-000Q8H-Ia for pgsql-bugs@lists.postgresql.org; Tue, 22 Aug 2023 19:22:56 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 921B3240006; Tue, 22 Aug 2023 19:22:48 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------DaCuKJvIgSICO1ArQh9WvzXY" Message-ID: Date: Tue, 22 Aug 2023 15:22:46 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() Content-Language: en-US To: Tom Lane Cc: Alvaro Herrera , Andres Freund , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org References: <20230821123337.fytudn7wtjlgtttk@alvherre.pgsql> <7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net> <2863241.1692635422@sss.pgh.pa.us> From: Andrew Dunstan In-Reply-To: <2863241.1692635422@sss.pgh.pa.us> X-GND-Sasl: adsend@dunslane.net List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------DaCuKJvIgSICO1ArQh9WvzXY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-08-21 Mo 12:30, Tom Lane wrote: > Andrew Dunstan 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 --------------DaCuKJvIgSICO1ArQh9WvzXY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


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


  


--------------DaCuKJvIgSICO1ArQh9WvzXY--