Re: Large expressions in indexes can't be stored (non-TOASTable) - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Large expressions in indexes can't be stored (non-TOASTable)
Date
Msg-id 18a111db-9f31-449c-a14b-61779a69f344@app.fastmail.com
Whole thread Raw
In response to Re: Large expressions in indexes can't be stored (non-TOASTable)  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Large expressions in indexes can't be stored (non-TOASTable)
List pgsql-hackers
On Wed, Apr 9, 2025, at 4:05 PM, Nathan Bossart wrote:
On Wed, Apr 09, 2025 at 01:20:29PM +0900, Michael Paquier wrote:
> I guess that's the consensus, then.  No objections to the removal here.

That would look like the attached.  There are still a couple of other known
TOAST snapshot issues I need to revisit, but this sidesteps a few of them.
But this'll need to wait for a couple of months until v19 development
begins.

LGTM. I have a few suggestions.
 
+   /*
+    * To avoid needing a TOAST table for pg_replication_origin, we restrict
+    * replication origin names to 512 bytes.  This should be more than enough
+    * for all practical use.
+    */
+   if (strlen(roname) > MAX_RONAME_LEN)
+       ereport(ERROR,

I wouldn't duplicate the comment. Instead, I would keep it only in origin.h.

+                errdetail("Repilcation origin names must be no longer than %d bytes.",
+                          MAX_RONAME_LEN)));

s/Repilcation/Replication/

+#define MAX_RONAME_LEN (512)

It is just a cosmetic suggestion but I usually use parentheses when it is an
expression but don't include it for a single number.

Should we document this maximum length?


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.
Next
From: David Rowley
Date:
Subject: Re: n_ins_since_vacuum stats for aborted transactions