Re: Atomics hardware support table & supported architectures - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Atomics hardware support table & supported architectures
Date
Msg-id 20140624170337.GA1242903@tornado.leadboat.com
Whole thread Raw
In response to Re: Atomics hardware support table & supported architectures  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Atomics hardware support table & supported architectures  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jun 23, 2014 at 05:16:15PM +0200, Andres Freund wrote:
> On 2014-06-23 10:29:54 -0400, Robert Haas wrote:
> > Telling people that
> > they can't have even the most minimal platform support code in
> > PostgreSQL unless they're willing to contribute and maintain a BF VM
> > indefinitely is not very friendly.  Of course, the risk of their
> > platform getting broken is higher if they don't, but that's different
> > than making it a hard requirement.
> 
> I agree that we shouldn't actively try to break stuff. But having to
> understand & blindly modify unused code is on the other hand of actively
> breaking platforms. It's actively hindering development.

What I'm hearing is that you see two options, (1) personally authoring
e.g. sparcv8 code or (2) purging the source tree of sparcv8 code before
submitting the patch that would otherwise change it.  I favor middle ground
that lets minor platforms pay their own way.  Write your changes with as
little effort as you wish toward whether they run on sparcv8.  If they break
sparcv8, then either (a) that was okay, or (b) a user will show up with a
report and/or patch, and we'll deal with that.

For any minor-platform user sighing now, the community offers an unbeatable
deal on PostgreSQL committer time.  Provide a currently-passing buildfarm
member, and no PostgreSQL committer will be content until his new code works
there.  How can you pass that up?

(By "break sparcv8", I mean a build failure, test suite failure, or large
performance regression.  If a change has the potential to make some
architectures give wrong answers only at odd times, that's a different kind of
problem.  For that reason, actively breaking Alpha is a good thing.)

> > But I think this is all a bit off-topic for this thread.  Andres has
> > already implemented a fallback for people who haven't got CAS and
> > fetch-and-add on their platform, so whether or not we deprecate some
> > more platforms has no bearing at all on this patch.
> 
> While I indeed have that fallback code, that's statement is still not
> entirely true. We still need to add atomics support for lots of
> platforms, otherwise they're just going to be 'less supported' than
> now. Are we fine with that and just'll accept patches?

+1

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: idle_in_transaction_timeout
Next
From: Tom Lane
Date:
Subject: Re: idle_in_transaction_timeout