Re: A small note on the portability of cmake - Mailing list pgsql-hackers

From Andres Freund
Subject Re: A small note on the portability of cmake
Date
Msg-id 20190120194153.7d7wspfstyatjmei@alap3.anarazel.de
Whole thread Raw
In response to Re: A small note on the portability of cmake  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2019-01-20 14:37:43 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-01-20 10:15:53 -0500, Tom Lane wrote:
> >> Indeed, the main reason why I'm interested in keeping this old dinosaur
> >> going at all is that it is so different from other platforms in terms
> >> of what we can assume about spinlocks and atomic ops.  Keeps us honest.
> 
> > FWIW, while that clearly is the policy right now, I quite doubt that
> > it's beneficial. It's not like there's going to be new hardware
> > platforms without at least cmpxchg / ll/sc support. So I'm not seeing
> > what not requiring them keeps us honest about.
> 
> I think you're being short-sighted.  I agree that any reasonable new
> hardware platform would have that functionality in some form, but
> it won't necessarily be exactly like x86_64 does it.

I agree on that part.  I can't see them doing something as weird as HPPA
however - yes there'll be some ll/sc and some cmpxchg style archs, and
perhaps their alignment requirements will be different, but not much
more than that. And that's largely what we already have covered.


> The particular things I think HPPA is keeping us honest about have to
> do with the size of spinlocks and whether they initialize to zero or
> not.  See e.g. 6b93fcd14 for an actual bug caught by that.

Sure.  But it also increases the test matrix, requires adding code for
fallbacks, makes dependencies more painful as evidenced here.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A small note on the portability of cmake
Next
From: Andres Freund
Date:
Subject: Why does execReplication.c lock tuples?