Обсуждение: Time to retire Windows XP buildfarm host?
Windows XP has been past end of life for quite some time. Nevertheless I have kept my instance running with three buildfarm members: frogmouth, currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but I'm not 100% sure) started causing a compiler segmentation fault on frogmouth, the mingw/gcc-4.5.0 animal running on this machine. I could try to remedy the problem, either by making a patch or updating the compiler, or I could retire frogmouth and keep the other animals running, or I could simply retire the machine. We have coverage of more modern instances of all these animals, so shutting down the machine probably wouldn't be any great loss, and would lessen my maintenance burden a bit :-). Does anyone have any strong opinion in favor of keeping any of these animals running? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Windows XP has been past end of life for quite some time. Nevertheless I
> have kept my instance running with three buildfarm members: frogmouth,
> currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but
> I'm not 100% sure) started causing a compiler segmentation fault on
> frogmouth, the mingw/gcc-4.5.0 animal running on this machine.
> ...
> Does anyone have any strong opinion in favor of keeping any of these
> animals running?
Hm, a look through our commit logs finds multiple mentions of each of
these animals as having been the only one showing a particular portability
issue. So I'm worried about loss of portability coverage. Are you sure
that the animals' build options and choices of toolchains are replicated
elsewhere?
regards, tom lane
On 12/05/2016 11:17 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Windows XP has been past end of life for quite some time. Nevertheless I >> have kept my instance running with three buildfarm members: frogmouth, >> currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but >> I'm not 100% sure) started causing a compiler segmentation fault on >> frogmouth, the mingw/gcc-4.5.0 animal running on this machine. >> ... >> Does anyone have any strong opinion in favor of keeping any of these >> animals running? > Hm, a look through our commit logs finds multiple mentions of each of > these animals as having been the only one showing a particular portability > issue. So I'm worried about loss of portability coverage. Are you sure > that the animals' build options and choices of toolchains are replicated > elsewhere? > > Not exactly the same, no. e.g. jacana is similar but it doesn't build with python, tcl or openssl, and does build with nls, it's 64bit vs 32bit, and it runs a more modern compiler on a more modern OS. If you think it's worth it I will put some effort into fixing frogmouth. I can certainly keep the others running for a while with little difficulty. I will disable frogmouth until I get a chance to look for a fix - next week at the earliest. cheers andrew
Hi, On 2016-12-05 10:56:00 -0500, Andrew Dunstan wrote: > Windows XP has been past end of life for quite some time. Nevertheless I > have kept my instance running with three buildfarm members: frogmouth, > currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but I'm > not 100% sure) started causing a compiler segmentation fault on frogmouth, > the mingw/gcc-4.5.0 animal running on this machine. > I could try to remedy the problem, either by making a patch or updating the > compiler, or I could retire frogmouth and keep the other animals running, or > I could simply retire the machine. We have coverage of more modern instances > of all these animals, so shutting down the machine probably wouldn't be any > great loss, and would lessen my maintenance burden a bit :-). > Does anyone have any strong opinion in favor of keeping any of these animals > running? I think we'd have to officially de-support postgres for winxp in that case. Which seems perfectly fine for HEAD, but not so nice for the backbranches, without a warning at least. I doubt we want to support XP for the next five years, even in the old branches, but we should give some heads up. At least a while back XP was still heavily used in embedded stuff, sometimes including postgres even. I think it might be good to introduce a general formal policy of de-supporting platforms a year or three after their OS support ended. Regards, Andres
On Mon, Dec 5, 2016 at 11:46 AM, Andres Freund <andres@anarazel.de> wrote: > I think it might be good to introduce a general formal policy of > de-supporting platforms a year or three after their OS support > ended. I agree. If possible, I'd like it to be more like 3 years than 1 year but that may not be possible in all cases without an unreasonable amount of work. Since PostgreSQL is a database [citation needed], and since upgrading to a new database version can be a pretty involved procedure in some environments, it's a lot better for users if we don't deprecate things sooner than is really necessary. On the other hand, it's become clear - at least to me - that supporting systems that don't really exist in the wild any more can be a real pain. pademelon is a good example. I don't mind keeping that working if Tom is willing to maintain it, but here's the thing: if a certain portability "problem" only shows up on machines running 20-year-old operating systems, how much of a problem is it, really? And how realistic is that anybody other than Tom will be able to help fix any issues that we do find, given that probably nobody but Tom has access to a machine like that? It's sort of sad to think that getting a modern PostgreSQL to compile on the UNIX machines I used in high school is probably hopeless, but the flip side is that we can't realistically maintain ports to systems to which none of us have access, and we can maintain ports to systems to which only a few of us have access only if those people are willing to be fairly involved in fixing any non-trivial issues that pop up. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> pademelon is a good example. I don't mind keeping that working if Tom
> is willing to maintain it, but here's the thing: if a certain
> portability "problem" only shows up on machines running 20-year-old
> operating systems, how much of a problem is it, really?
For the record, I don't see keeping things working on gaur/pademelon as an
end in itself. My feeling about that, as with prairiedog which is also a
museum piece[1], is more like this: when we move the compatibility
goalposts enough to break these old systems, we should know it and make a
deliberate decision that it's OK and not worth working around. At which
point I'll shut them down. But I don't want loss of old-system
compatibility to happen blindly. I think the same is probably true for a
number of other pretty-old critters in the buildfarm, for example coypu
--- it seems unlikely that many people still run such an old release of
NetBSD, but that doesn't mean we want to break it unintentionally.
> ... we can't
> realistically maintain ports to systems to which none of us have
> access, and we can maintain ports to systems to which only a few of us
> have access only if those people are willing to be fairly involved in
> fixing any non-trivial issues that pop up.
Sure, I think that comes with the territory of being a buildfarm owner.
regards, tom lane
[1] Literally. https://www.moma.org/collection/works/82134
On 12/05/2016 11:38 AM, Andrew Dunstan wrote: > > > On 12/05/2016 11:17 AM, Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> Windows XP has been past end of life for quite some time. >>> Nevertheless I >>> have kept my instance running with three buildfarm members: frogmouth, >>> currawong and brolga. Howeever, a recent commit (apparently fa2fa99, >>> but >>> I'm not 100% sure) started causing a compiler segmentation fault on >>> frogmouth, the mingw/gcc-4.5.0 animal running on this machine. >>> ... >>> Does anyone have any strong opinion in favor of keeping any of these >>> animals running? >> Hm, a look through our commit logs finds multiple mentions of each of >> these animals as having been the only one showing a particular >> portability >> issue. So I'm worried about loss of portability coverage. Are you sure >> that the animals' build options and choices of toolchains are replicated >> elsewhere? >> >> > > > Not exactly the same, no. e.g. jacana is similar but it doesn't build > with python, tcl or openssl, and does build with nls, it's 64bit vs > 32bit, and it runs a more modern compiler on a more modern OS. > > If you think it's worth it I will put some effort into fixing > frogmouth. I can certainly keep the others running for a while with > little difficulty. I will disable frogmouth until I get a chance to > look for a fix - next week at the earliest. > > ... and miraculously it has fixed itself. cheers andrew
Andrew Dunstan wrote: > ... and miraculously it has fixed itself. And it failed again today, once. Today I noticed that it's running gcc 4.5.0. But for the 4.5 branch, the GCC guys put out a few releases before abandoning it, and there are some compiler segmentation faults fixed in some of these releases, visible here: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.1 https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.2 https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.3 https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.4 I think it'd be worthwhile to upgrade to the latest in that branch. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Dec 24, 2016 at 7:48 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Andrew Dunstan wrote: > >> ... and miraculously it has fixed itself. > > And it failed again today, once. > > Today I noticed that it's running gcc 4.5.0. But for the 4.5 branch, > the GCC guys put out a few releases before abandoning it, and there are > some compiler segmentation faults fixed in some of these releases, > visible here: > > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.1 > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.2 > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.3 > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.4 > > I think it'd be worthwhile to upgrade to the latest in that branch. FWIW, I also saw segmentation faults with MinGW using gcc 4.8.1 in my environments, after fetching the newest supported by the builds :( Any configuration on Windows out of MSVC is depressing. -- Michael