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 <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1qY7OD-000peK-Rx
	for pgsql-bugs@arkaria.postgresql.org; Mon, 21 Aug 2023 16:04:25 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1qY7OC-0089gG-Kq
	for pgsql-bugs@arkaria.postgresql.org; Mon, 21 Aug 2023 16:04:24 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <andrew@dunslane.net>)
	id 1qY7OC-0089ff-Bi
	for pgsql-bugs@lists.postgresql.org; Mon, 21 Aug 2023 16:04:24 +0000
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by makus.postgresql.org with esmtps  (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <andrew@dunslane.net>)
	id 1qY7O8-000BD6-Hb
	for pgsql-bugs@lists.postgresql.org; Mon, 21 Aug 2023 16:04:22 +0000
Received: by mail.gandi.net (Postfix) with ESMTPSA id 93A161C0004;
	Mon, 21 Aug 2023 16:04:15 +0000 (UTC)
Content-Type: multipart/alternative;
 boundary="------------OVq23F5kzhhbH72Al2h6u0kw"
Message-ID: <7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net>
Date: Mon, 21 Aug 2023 12:04:14 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Content-Language: en-US
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
References: <20230821123337.fytudn7wtjlgtttk@alvherre.pgsql>
From: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside
 ExecEvalFieldStoreDeForm()
In-Reply-To: <20230821123337.fytudn7wtjlgtttk@alvherre.pgsql>
X-GND-Sasl: adsend@dunslane.net
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/7dc0e894-62ff-381c-b633-fa68250dd586%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------OVq23F5kzhhbH72Al2h6u0kw
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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

--------------OVq23F5kzhhbH72Al2h6u0kw
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2023-08-21 Mo 08:33, Alvaro Herrera
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20230821123337.fytudn7wtjlgtttk@alvherre.pgsql">
      <pre class="moz-quote-pre" wrap="">Hello,

On 2023-Jul-12, Andrew Dunstan wrote:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">+			entry = hash_search(missing_cache, &amp;key, HASH_ENTER, &amp;found);
+
+			if (!found)
+			{
+				/* cache miss, so we need a non-transient copy of the datum */
+				oldctx = MemoryContextSwitchTo(TopMemoryContext);
+				entry-&gt;value =
+					datumCopy(attrmiss-&gt;am_value, false, att-&gt;attlen);
+				MemoryContextSwitchTo(oldctx);
+			}
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Hmm ... when exactly do these values get freed if no longer needed?  Is
the theory that leaking them is not relevant?</pre>
    </blockquote>
    <p><br>
    </p>
    <p>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.<br>
    </p>
    <p>
      <br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<br>
    </p>
    <pre class="moz-signature" signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------OVq23F5kzhhbH72Al2h6u0kw--