Re: Spinlocks and compiler/memory barriers

On Wed, Jul 2, 2014 at 4:06 AM, Mark Cave-Ayland
<mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> wrote:
> The point I wanted to make was that there are certain applications for which
> SPARCv8 is still certified for particular military/aerospace use. While I
> don't use it myself, some people are still using it enough to want to
> contribute QEMU patches.
>
> In terms of QEMU, the main reason for mentioning it was that if the
> consensus were to keep SPARCv8 support then this could be one possible way
> to provide basic buildfarm support (although as Tom rightly points out,
> there would need to be testing to build up confidence that the emulator does
> the right thing in a multiprocessor environment).

I think we're getting off-track here. The PostgreSQL project is
always willing to accept new buildfarm machines. In the absence of
buildfarm machines, we try not to go around randomly breaking things
that were previously working. But the current situation is that we
have good reason to suspect that a couple of very old platforms are
subtly broken. In that situation, I think removing the
thought-to-be-broken-code is the only sensible approach.

Now, we're not crossing any sort of Rubicon here. If buildfarm
machines show up - or, hell, if ONE person with access to the hardware
OR a simulator shows up and can compile test EVEN ONCE that a patch to
re-add support compiles and that the regression tests pass - then we
can add support back in two shakes of a lamb's tail. In the meantime,
leaving broken code in our tree is not a service to anyone.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company