| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: scary patch contest |
| Date: | 2026-08-26 00:17:53 |
| Message-ID: | CA+TgmoYezjKo5owN2ngY+tZ_g_f+tiY=zfwo4jA+7mh+J5CiXA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 25, 2026 at 6:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> FWIW, I am quite afraid of #5, mainly because we are *still*
> discussing fixes that will require parsetree and/or catalog changes
> and thus catversion bumps. (There are two such threads on the
> open-items list, and possibly more that I've not noticed.) At this
> point I'd be willing to bet dinner that if we ship it in v19 there
> will be post-release bug discoveries that are unfixable until v20.
Without opining on that feature too specifically, I don't think
features that may need catversion bumps belong in v19 at this point. I
guess if some feature needs a trivial catversion bump and we're pretty
confident nothing more will be needed afterward then it might be OK to
let it slide, but really, the time for working out what the catalogs
should look like was sometime well in advance of feature freeze, not
four months after it. My gut reaction is that anything that still
needs a catversion bump at this point should be reverted at least out
of v19, *especially* if it's not clear what that catversion bump needs
to look like.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ajin Cherian | 2026-08-26 00:21:35 | Re: Apply worker can pick an invalid index for REPLICA IDENTITY FULL lookups |
| Previous Message | Yuhang Qiu | 2026-08-25 23:34:34 | Re: Allow aggressive VACUUM to freeze without a cleanup lock |