On 2024-Nov-14, Michael Paquier wrote:
> On Wed, Nov 13, 2024 at 02:52:31PM -0500, Robert Haas wrote:
> > On Wed, Nov 13, 2024 at 11:05 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >> So, my question now is, would there be much opposition to backpatching
> >> beb4e9ba1652 + 1fb17b190341 to REL_14_STABLE?
> >
> > It seems like it's been long enough now that if the new logic had
> > major problems we probably would have found them by now; so I feel
> > like it's probably pretty safe. Perhaps it's questionable how many
> > people we'll help by back-patching this into one additional release,
> > but if you feel it's worth it I wouldn't be inclined to argue.
>
> +1 for v14 as this version is still around for two years.
Thanks, I have pushed it now.
> Even getting that down to v13 would be OK for me at this stage, as,
> assuming that something is messed up for a reason or another, we would
> still have one year to address any issue that could pop up on
> REL_13_STABLE.
>
> Now, the conflicts that exist between v14 and v13 in pgarch.[c|h] are
> really risky due to the design changes done in d75288fb27b8, so it is
> much better to leave v13 out of scope..
Yeah, my first intention was to push it to 13 as well. I did try to add
a minimal version of d75288fb27b8 to get it there (it had a lot of
conflicts but it was easy to resolve by just removing a few lines), but
the tests fail with pgarchiver sometimes hanging. Clearly an indicator
that it would be far too risky to backpatch it there. I don't think
it's reasonable to expect much more from that. Let's just tell people
to upgrade if they have issues.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)
