From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Spinlocks and compiler/memory barriers |
Date: | 2014-07-01 16:22:59 |
Message-ID: | CA+TgmoZXxazyByx5YtKJQMXhhdOHZizmWxVCxw5bnFPZTZAS2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-07-01 16:42:06 | Re: RLS Design |
Previous Message | Robert Haas | 2014-07-01 15:27:33 | Re: Set new system identifier using pg_resetxlog |