Re: 9.4 broken on alpha

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: 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:49:46
Message-ID: 22535.1440607786@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Michael Cree wrote:
>> That is disappointing to hear. Why is that? It is still in use on
>> Alpha. What is the maintenance load for keeping the Alpha arch
>> specific code?

> The amount of code that was removed by the commit isn't all that much:
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a6d488cb538c8761658f0f7edfc40cecc8c29f2d
> but there's been rather a lot of work after that to add support for
> atomic primitives as well as barriers, which would presumably not
> trivial to implement and test on Alpha. Someone would have to volunteer
> to writing, testing and maintaining that code.

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.

> A buildfarm machine would be mandatory, too.

That, however, is not negotiable.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2015-08-26 16:54:24 Re: Freeze avoidance of very large table.
Previous Message Alexander Korotkov 2015-08-26 16:20:21 Re: WIP: Rework access method interface