Re: Spinlocks and compiler/memory barriers
От | Robert Haas |
---|---|
Тема | Re: Spinlocks and compiler/memory barriers |
Дата | |
Msg-id | CA+TgmoZXxazyByx5YtKJQMXhhdOHZizmWxVCxw5bnFPZTZAS2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Spinlocks and compiler/memory barriers (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Spinlocks and compiler/memory barriers
(Merlin Moncure <mmoncure@gmail.com>)
Re: Spinlocks and compiler/memory barriers (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund <andres@2ndquadrant.com> wrote: >> You know, looking at this, I wonder if we shouldn't just remove >> support for ARMv5 instead of making a blind stab at a fix. > > Well, I argued that way for a while ;). We don't even need to really > desupport it, but just say it's not supported for gcc < 4.4. Yeah, I didn't realize at the time that you were making that argument that the existing code was thought to be broken on its own terms. Removing probably-working code that we just can't test easily is, in my mind, quite different from removing probably-broken code for which we can't test a fix. By the time PostgreSQL 9.5 is released, GCC 4.4 will be six years old, and telling people on an obscure platform that few operating system distributions support that they can't use a brand-new PostgeSQL with a seven-year-old compiler doesn't seem like a serious problem, especially since the only alternative we can offer is compiling against completely-untested code. >> Since we have a Sun Studio machine in the buildfarm, we shouldn't give >> up on SPARC completely, but maybe we should only add the cases for >> sparcv8+ and above? That at least has some chance of getting tested. > > That we have code for sparcv7 is ridiculous btw. Sparcv8 (not 8+/9) is > from 1992. v7/sun4c been dropped from solaris 8 if I see that correctly. > > I agree that v8 (in contrast to v8+ aka v9 in 32bit mode) support has to > go as well. I'd personally vote for backpatching a note to > installation.sgml saying that it's probably not working, and not do > anything else there. That means we also should replace the ldstub by cas > in the the gcc inline assembly - but we have buildfarm members for that, > so it's not too bad. If you want to do that, it's fine with me. What I would do is: - Back-patch the addition of the sparcv8+ stuff all the way. If anyone's running anything older, let them complain... - Remove the special case for MIPS without gcc intrinsics only in master, leaving the back-branches broken. If anyone cares, let them complain... - Nothing else. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: