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 <alvhe...@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)
