On Thu, Apr 11, 2024 at 11:27 PM Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Apr 11, 2024 at 1:46 PM Alexander Korotkov <aekorot...@gmail.com> > wrote: > > I understand that I'm the bad guy of this release, not sure if my > > opinion counts. > > > > But what is going on here? I hope this work is targeting pg18. > > Otherwise, do I get this right that this post feature-freeze works on > > designing a new API? Yes, 27bc1772fc masked the problem. But it was > > committed on Mar 30. So that couldn't justify why the proper API > > wasn't designed in time. Are we judging different commits with the > > same criteria? > > I mean, Andres already said that the cleanup was needed possibly in > 17, and possibly in 18. > > As far as fairness is concerned, you'll get no argument from me if you > say the streaming read stuff was all committed far later than it > should have been. I said that in the very first email I wrote on the > "post-feature freeze cleanup" thread. But if you're going to argue > that there's no opportunity for anyone to adjust patches that were > sideswiped by the reverts of your patches, and that if any such > adjustments seem advisable we should just revert the sideswiped > patches entirely, I don't agree with that, and I don't see why anyone > would agree with that. I think it's fine to have the discussion, and > if the result of that discussion is that somebody says "hey, we want > to do X in 17 for reason Y," then we can discuss that proposal on its > merits, taking into account the answers to questions like "why wasn't > this done before the freeze?" and "is that adjustment more or less > risky than just reverting?" and "how about we just leave it alone for > now and deal with it next release?".
I don't think 041b96802e could be sideswiped by 27bc1772fc. The "Use streaming I/O in ANALYZE" patch has the same issue before 27bc1772fc, which was committed on Mar 30. So, in the worst case 27bc1772fc steals a week of work. I can imagine without 27bc1772fc , a new API could be proposed days before FF. This means I saved patch authors from what you name in my case "desperate rush". Huh! > > IMHO, 041b96802e should be just reverted. > > IMHO, it's too early to decide that, because we don't know what change > concretely is going to be proposed, and there has been no discussion > of why that change, whatever it is, belongs in this release or next > release. > > I understand that you're probably not feeling great about being asked > to revert a bunch of stuff here, and I do think it is a fair point to > make that we need to be even-handed and not overreact. Just because > you had some patches that had some problems doesn't mean that > everything that got touched by the reverts can or should be whacked > around a whole bunch more post-freeze, especially since that stuff was > *also* committed very late, in haste, way closer to feature freeze > than it should have been. At the same time, it's also important to > keep in mind that our goal here is not to punish people for being bad, > or to reward them for being good, or really to make any moral > judgements at all, but to produce a quality release. I'm sure that, > where possible, you'd prefer to fix bugs in a patch you committed > rather than revert the whole thing as soon as anyone finds any > problem. I would also prefer that, both for your patches, and for > mine. And everyone else deserves that same consideration. I expressed my thoughts about producing a better release without a desperate rush post-FF in my reply to Andres [2]. Links. 1. https://www.postgresql.org/message-id/CA%2BTgmobZUnJQaaGkuoeo22Sydf9%3DmX864W11yZKd6sv-53-aEQ%40mail.gmail.com 2. https://www.postgresql.org/message-id/CAPpHfdt%2BcCj6j6cR5AyBThP6SyDf6wxAz4dU-0NdXjfpiFca7Q%40mail.gmail.com ------ Regards, Alexander Korotkov
