Re: Atomics hardware support table & supported architectures

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Atomics hardware support table & supported architectures
Date: 2014-06-24 17:03:37
Message-ID: 20140624170337.GA1242903@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-24 17:05:10 Re: idle_in_transaction_timeout
Previous Message Josh Berkus 2014-06-24 16:58:08 Re: idle_in_transaction_timeout