Re: 9.4 broken on alpha

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Cree <mcree(at)orcon(dot)net(dot)nz>, pgsql-hackers(at)postgresql(dot)org, "Aaron W(dot) Swenson" <titanofold(at)gentoo(dot)org>
Subject: Re: 9.4 broken on alpha
Date: 2015-08-26 16:59:41
Message-ID: 20150826165941.GA12004@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-08-26 12:49:46 -0400, Tom Lane wrote:
> As far as that goes, we do have fallback atomics code that's supposed to
> work on anything (and not be unusably slow). So in principle,
> resurrecting the Alpha spinlock code ought to be enough to get back to the
> previous level of support. Coding Alpha atomic primitives would likely
> be worth doing, if there's somebody out there who's excited enough to take
> it on; but that could happen later, and incrementally.

Actually, on linux and most other OSs it should just use the generic gcc
based implementation and be pretty close to optimal. The only thing it'd
need would be to define the memory barriers, so the fallback
implementation of those isn't used.

But I really strongly object to re-introducing alpha support. Having to
care about data dependency barriers is a huge pita, and it complicates
code for everyone. And we'd have to investigate a lot of code to
actually make it work reliably. For what benefit?

> > A buildfarm machine would be mandatory, too.
>
> That, however, is not negotiable.

If we really were to re-introduce this we'd need an actual developer
machine to run tests against.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-08-26 17:10:01 Re: 9.5 release notes
Previous Message Masahiko Sawada 2015-08-26 16:54:24 Re: Freeze avoidance of very large table.