| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Large expressions in indexes can't be stored (non-TOASTable) |
| Date: | 2025-04-30 00:57:46 |
| Message-ID: | aBF1ii89jdzQsVvB@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-04-30 01:03:12 | Re: expand on_error ignore error handling scope |
| Previous Message | Michael Paquier | 2025-04-30 00:29:59 | Re: add --sequence-data to pg_dumpall |