From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, 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:27:43 |
Message-ID: | 20140624172743.GD24114@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-06-24 10:22:08 -0700, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> >> 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.
>
> > Not sure what you mean with the 'actively breaking Alpha' statement?
> > That we should drop Alpha?
>
> +1. Especially with no buildfarm critter. Would anyone here care
> to bet even the price of a burger that Alpha isn't broken already?
I'd actually be willing to bet a fair amount of money that it already is
broken. Especially in combination with an aggressively optimizing
compiler.
Then let's do that.
> Even if we *had* an Alpha in the buildfarm, I'd have pretty small
> confidence in whether our code really worked on it. The buildfarm
> tests just don't stress heavily-concurrent behavior enough.
Yea.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-24 17:29:51 | Re: idle_in_transaction_timeout |
Previous Message | Noah Misch | 2014-06-24 17:27:29 | Re: Atomics hardware support table & supported architectures |