Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Euler Taveira <euler@eulerto.com>, Amit Kapila <amit.kapila16@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, "Jonathan S. Katz" <jkatz@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-30T00:57:46Z
Lists: pgsql-hackers 
On Tue, Apr 29, 2025 at 02:01:54PM -0400, Tom Lane wrote:
> I'm inclined to argue that it's a bug fix and therefore still in-scope
> for v18.  The fact that we can't back-patch such a change is all the
> more reason to not let it slide another year.

Not on the RMT.  I have looked at the patch, and I would agree with
doing that now in v18 rather than wait for v19 to open up.

> But probably the RMT should make the call.

Yes.

This has been mentioned upthread, but I am questioning the wisdom of
putting the restriction based on MAX_RONAME_LEN only in
pg_replication_origin_create(), while replorigin_create() is the one
that actually matters.  While it is true that these restrictions are
enforced for the current callers in core, it could also be called by
stuff outside of core.  It seems important to me to let these
potential callers know about the restriction in place.
--
Michael

Commits

  1. Ensure we have a snapshot when updating various system catalogs.

  2. Remove pg_replication_origin's TOAST table.

  3. Restrict password hash length.

  4. Ensure we have a snapshot when updating pg_index entries.

  5. Add TOAST table to pg_index.

  6. Add toast tables to most system catalogs