Re: Spinlocks and compiler/memory barriers

On 2014-07-01 11:46:19 -0500, Merlin Moncure wrote:
> On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.
>
> A few years back I ported the postresql client libraries and a few
> other pieces of software (in particular subversion) to a lot of
> obscure platforms (old sparc, hpux, irix, older aix, etc etc).
> Getting a modern gcc working on those platforms (with the possible
> exception of aix) is in many cases difficult or impossible.

Well, we're talking about a case where the current code is
*broken*. Subtly so. Where we have no way of testing potential fixes. If
you/somebody steps up to fix & test that, cool. But I don't see it as a
service to anyone to ship broken stuff.

> So requiring new gcc is exactly equivalent to desupporting.

Yea, right. The case we're talking about here is armv5 and some armv6's
(the current fallback inline assembly doesn't work on all v6s). If
postgres were indeed in use and updated on such a platform it'd be cross
compiled with near certainty.

The other case is sparcv7 and sparcv8 (not v8+). The former has been
dropped from solaris8, the latter from solaris9.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services