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.96) (envelope-from ) id 1vIZZe-005p0d-1M for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Nov 2025 21:37:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vIZZb-002ePO-1I for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Nov 2025 21:37:15 +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.96) (envelope-from ) id 1vIZZa-002ePG-31 for pgsql-hackers@lists.postgresql.org; Mon, 10 Nov 2025 21:37:14 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vIZZZ-006RLi-0M for pgsql-hackers@postgresql.org; Mon, 10 Nov 2025 21:37:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5AALbAsI1983210; Mon, 10 Nov 2025 16:37:10 -0500 From: Tom Lane To: Nathan Bossart cc: Maxim Zibitsker , pgsql-hackers@postgresql.org Subject: Re: Support allocating memory for large strings In-reply-to: References: <5B146D62-35AE-4822-9B98-37E386AFB942@gmail.com> <1357347.1762569165@sss.pgh.pa.us> Comments: In-reply-to Nathan Bossart message dated "Mon, 10 Nov 2025 14:35:09 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1983208.1762810630.1@sss.pgh.pa.us> Date: Mon, 10 Nov 2025 16:37:10 -0500 Message-ID: <1983209.1762810630@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > FWIW something I am hearing about more often these days, and what I believe > Maxim's patch is actually after, is the 1GB limit on row size. Even if > each field doesn't exceed 1GB (which is what artifacts.md seems to > demonstrate), heap_form_tuple() and friends can fail to construct the whole > tuple. This doesn't seem to be covered in the existing documentation about > limits [0]. Yeah. I think our hopes of relaxing the 1GB limit on individual field values are about zero, but maybe there is some chance of allowing tuples that are wider than that. The notion that it's a one-line fix is still ludicrous though :-( One big problem with a scheme like that is "what happens when I try to make a bigger-than-1GB tuple into a composite datum?". Another issue is what happens when a wider-than-1GB tuple needs to be sent to or from clients. I think there are assumptions in the wire protocol about message lengths fitting in an int, for example. Even if the protocol were okay with it, I wouldn't count on client libraries not to fall over. On the whole, it's a nasty can of worms, and I stand by the opinion that the cost-benefit ratio of removing the limit is pretty awful. regards, tom lane