| 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-27 13:59:25 |
| Message-ID: | 20140627135925.GB18288@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?
Here's a patch removing alpha/true64/osf/1 support. I think I got most
relevant references, not sure if I missed something.
Since there seems to be (unanimous?) support for dropping alpha and some
patches coming up that need to deal with platform dependent stuff it
seems sensible to do this first.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Remove-Alpha-and-Tru64-support.patch | text/x-patch | 13.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vik Fearing | 2014-06-27 14:11:21 | Re: change alter user to be a true alias for alter role |
| Previous Message | Robert Haas | 2014-06-27 11:45:23 | Re: idle_in_transaction_timeout |