Re: Atomics hardware support table & supported architectures

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Atomics hardware support table & supported architectures
Date: 2014-06-19 16:17:55
Message-ID: 20140619161755.GC16260@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-06-19 11:00:51 -0400, Alvaro Herrera wrote:
> Merlin Moncure wrote:
> > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> > > Let's not pretend to support platforms we have no practical way of
> > > verifying.
> >
> > This is key. The buildfarm defines the set of platforms we support.
>
> This means that either Renesas should supply us with a bunch of
> buildfarm members for their SuperH and M32R stuff, or they should be
> considered unsupported as well.

Hm. I've missed SuperH in my comparison - it's not actually documented
to be a supported platform...

> I don't really care all that much about Linux and the glibc situation on
> M32R; I mean that platform is weird enough that it might well have its
> own, unheard-of Unix clone.

They have their own compiler for a some realtime os (not posix-y and
discontinued!) - but that doesn't support the gcc syntax used by
s_lock.h. So it's already not supported.

> But if people expect to use Postgres on it, we need BF members.

Yes. But I think it's exceedingly unlikely.

Greetings,

Andres Freund

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-19 16:18:22 Re: [bug fix] Memory leak in dblink
Previous Message Joe Conway 2014-06-19 16:08:56 Re: [bug fix] Memory leak in dblink