Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qJE9p-0002if-36 for pgsql-bugs@arkaria.postgresql.org; Tue, 11 Jul 2023 14:16:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qJE9n-0002QA-Dx for pgsql-bugs@arkaria.postgresql.org; Tue, 11 Jul 2023 14:15:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qJE9n-0002Pz-5q for pgsql-bugs@lists.postgresql.org; Tue, 11 Jul 2023 14:15:59 +0000 Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qJE9k-003UJ8-4f for pgsql-bugs@lists.postgresql.org; Tue, 11 Jul 2023 14:15:58 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 6A57A1C0008; Tue, 11 Jul 2023 14:15:53 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------Lbd20tHfMRSmf4aBfgpci4IU" Message-ID: <27522775-aa59-38d4-716e-c2de35bc3d5a@dunslane.net> Date: Tue, 11 Jul 2023 10:15:52 -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: Andres Freund Cc: Tom Lane , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org References: <1749275.1688132604@sss.pgh.pa.us> <1800418.1688152085@sss.pgh.pa.us> <3878b204-e9b4-6e09-9adb-7a37b8db34a6@dunslane.net> <20230702215420.mal2kg5a4kasme5j@awork3.anarazel.de> <213081.1688335023@sss.pgh.pa.us> <20230702221320.t2yr52ozuuzmhcdy@awork3.anarazel.de> <2649715f-eff4-efe3-6a8d-7126a8624bc3@dunslane.net> <133548e7-9d69-4b74-5b11-d0ab30a616ef@dunslane.net> <20230710195107.r4s3ig6llhy2j3zb@awork3.anarazel.de> From: Andrew Dunstan Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() In-Reply-To: <20230710195107.r4s3ig6llhy2j3zb@awork3.anarazel.de> 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. --------------Lbd20tHfMRSmf4aBfgpci4IU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-07-10 Mo 15:51, Andres Freund wrote: > Hi, > > On 2023-07-08 08:48:00 -0400, Andrew Dunstan wrote: >> On 2023-07-02 Su 22:15, Andrew Dunstan wrote: >>>>>> Separately, will this work correctly with procedures keeping values alive >>>>>> across transactions? >>>>> That might be an issue. But couldn't we make this cache just live for >>>>> the life of the process? It's unlikely to get large. >>>> I don't have a good handle about how big it'd end up being in some of the less >>>> common workloads. I can imagine workloads with temp tables or such churning >>>> through a lot of default values - often the "keyed by value" approach will >>>> save the day, but I imagine not always. >>> The maximum number of entries in the table is the number of pg_attribute >>> rows with atthasmissing = true and attbyval = false. In practice I >>> suspect that's mostly going to be fairly low. > It's not really bound by that, because the set of rows can change over > time. Particularly with temp tables. How many times are people going to add a new column with a non-null default to a temp table? Usually you know the shape you want for a temp table when you create it, I should think. Even in a long-running pgbouncer session I wouldn't expect this to balloon substantially. > > >> The thread seems to have died down a bit. Do we have a consensus on Tom's >> approach? > I guess so. It's far from pretty, but nobody really has come up with something > better. > OK, I'll send a revised patch. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com --------------Lbd20tHfMRSmf4aBfgpci4IU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 2023-07-10 Mo 15:51, Andres Freund wrote:
Hi,

On 2023-07-08 08:48:00 -0400, Andrew Dunstan wrote:

On 2023-07-02 Su 22:15, Andrew Dunstan wrote:

Separately, will this work correctly with procedures keeping values alive
across transactions?

That might be an issue.  But couldn't we make this cache just live for
the life of the process?  It's unlikely to get large.

I don't have a good handle about how big it'd end up being in some of the less
common workloads. I can imagine workloads with temp tables or such churning
through a lot of default values - often the "keyed by value" approach will
save the day, but I imagine not always.

The maximum number of entries in the table is the number of pg_attribute
rows with atthasmissing = true and attbyval = false. In practice I
suspect that's mostly going to be fairly low.

It's not really bound by that, because the set of rows can change over
time. Particularly with temp tables.


How many times are people going to add a new column with a non-null default to a temp table? Usually you know the shape you want for a temp table when you create it, I should think. Even in a long-running pgbouncer session I wouldn't expect this to balloon substantially.





The thread seems to have died down a bit. Do we have a consensus on Tom's
approach?

I guess so. It's far from pretty, but nobody really has come up with something
better.


OK, I'll send a revised patch.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com
--------------Lbd20tHfMRSmf4aBfgpci4IU--