On Sun, Oct 24, 2021 at 5:46 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Hmm ... I guess the question is how much work we feel like putting > into that, and how we'd track whether old branches still work, > and on what platforms. It could easily turn into a time sink > that's not justified by the value. I do see your point that there's > some value in it; I'm just not sure about the cost/benefit ratio.
Right. Well, we could leave it up to people who care to decide how much work they want to do, perhaps. But I do find it annoying that pg_dump is supposed to maintain compatibility with server releases that I can't easily build. Fortunately I don't patch pg_dump very often, but if I did, it'd be very difficult for me to verify that things work against really old versions. I know that you (Tom) do a lot of work of this type though. In my opinion, if you find yourself working on a project of this type and as part of that you do some fixes to an older branch to make it compile, maybe you ought to commit those so that the next person doesn't have the same problem. And maybe when we add support for newer versions of OpenSSL or Windows, we ought to consider back-patching those even to unsupported releases if someone's willing to do the work. If they're not, they're not, but I think we tend to strongly discourage commits to EOL branches, and I think maybe we should stop doing that. Not that people should routinely back-patch bug fixes, but stuff that makes it easier to build seems fair game. I don't think we need to worry too much about users getting the wrong impression. People who want to know what is supported are going to look at our web site for that information, and they are going to look for releases. I can't rule out the possibility that someone is going to build an updated version of 7.4 or 8.2 with whatever patches we might choose to commit there, but they're unlikely to think that means those are fully supported branches. And if they somehow do think that despite all evidence to the contrary, we can just tell them that they are mistaken. > One thing we could do that would help circumscribe the costs is to say > "we are not going to consider issues involving new compiler warnings > or bugs caused by more-aggressive optimization". We could mechanize > that pretty effectively by changing configure shortly after a branch's > EOL to select -O0 and no extra warning flags, so that anyone building > from branch tip would get those switch choices. I don't much like the idea of including -O0 because it seems like it could be confusing. People might not realize that that the build settings have been changed. I don't think that's really the problem anyway: anybody who hits compiler warnings in older branches could decide to fix them (and as long as it's a committer who will be responsible for their own work, I think that's totally fine) or enable -O0 locally. I routinely do that when I hit problems on older branches, and it helps a lot, but the way I see it, that's such an easy change that there's little reason to make it in the source code. What's a lot more annoying is if the compile fails altogether, or you can't even get past the configure step. -- Robert Haas EDB: http://www.enterprisedb.com
