Re: Spinlocks and compiler/memory barriers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Spinlocks and compiler/memory barriers
Date
Msg-id CA+TgmoYsd+_MBWfHUTZc0sPxvWsjnjHcM-NYNMs6SY198C84ww@mail.gmail.com
Whole thread Raw
In response to Re: Spinlocks and compiler/memory barriers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Spinlocks and compiler/memory barriers  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> 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.

I've gone ahead and done the second of these things.

Andres, do you want to go take a stab at fixing the SPARC stuff?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Rajmohan C
Date:
Subject: how to find the order of joins from Explain command XML plan output in PostgreSQL9.3.4
Next
From: Andres Freund
Date:
Subject: Re: Spinlocks and compiler/memory barriers