On 10/17/2013 09:45 AM, Robert Haas wrote:
>>> According to http://en.wikipedia.org/wiki/UnixWare, UnixWare is not
>>> dead, although there have been no new releases in 5 years.
Gee, I wonder why?
I'll point out that SCO laid off all of its packagers three or four
years ago. So nobody is packagi
On Fri, Oct 18, 2013 at 8:04 PM, Peter Geoghegan wrote:
> On Fri, Oct 18, 2013 at 9:55 AM, Ants Aasma wrote:
>> FWIW, I think that if we approach coding lock free algorithms
>> correctly - i.e. "which memory barriers can we avoid while being
>> safe", instead of "which memory barriers we need to
On 2013-10-18 18:36:03 +0200, Stefan Kaltenbrunner wrote:
> On 10/18/2013 06:29 PM, Andres Freund wrote:
> > On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
> >> hmm there are still some operating systems that "officially" support the
> >> alpha architecture which will likely result in pr
On Fri, Oct 18, 2013 at 9:55 AM, Ants Aasma wrote:
> FWIW, I think that if we approach coding lock free algorithms
> correctly - i.e. "which memory barriers can we avoid while being
> safe", instead of "which memory barriers we need to add to become
> safe" - then supporting Alpha isn't a huge amo
On Thu, Oct 17, 2013 at 3:10 PM, Robert Haas wrote:
> On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch wrote:
>> Removing support for alpha is a different animal compared to removing support
>> for non-gcc MIPS and most of the others in your list. A hacker wishing to
>> restore support for another M
On 10/18/2013 06:29 PM, Andres Freund wrote:
> On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
>> On 10/18/2013 02:41 PM, Robert Haas wrote:
>>> On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
On 10/17/13 12:45 PM, Robert Haas wrote:
> The attached patch, which I propos
On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
> On 10/18/2013 02:41 PM, Robert Haas wrote:
> > On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
> >> On 10/17/13 12:45 PM, Robert Haas wrote:
> >>> The attached patch, which I propose to apply relatively soon if nobody
> >>> objec
On 10/18/2013 02:41 PM, Robert Haas wrote:
> On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>> On 10/17/13 12:45 PM, Robert Haas wrote:
>>> The attached patch, which I propose to apply relatively soon if nobody
>>> objects, removes the IRIX port.
>>
>> +1
>
> Done. And here's a patch f
On Fri, Oct 18, 2013 at 9:39 AM, Tim Kane wrote:
> Just to be pedantic, commit message shows
> "support for Tru64 ended in 201."
>
> I think you mean 2012.
Duh, I'm a dork. Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
Just to be pedantic, commit message shows
"support for Tru64 ended in 201."
I think you mean 2012.
On 18/10/2013 13:41, "Robert Haas" wrote:
>On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>> On 10/17/13 12:45 PM, Robert Haas wrote:
>>> The attached patch, which I propose
On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
> On 10/17/13 12:45 PM, Robert Haas wrote:
>> The attached patch, which I propose to apply relatively soon if nobody
>> objects, removes the IRIX port.
>
> +1
Done. And here's a patch for removing the alpha architecture and
Tru64 UNIX (aka
On 10/17/13 12:45 PM, Robert Haas wrote:
> The attached patch, which I propose to apply relatively soon if nobody
> objects, removes the IRIX port.
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Wed, Oct 16, 2013 at 1:25 PM, Stefan Kaltenbrunner
wrote:
> On 10/16/2013 07:04 PM, Robert Haas wrote:
>> On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund
>> wrote:
>>> I think we should remove support the following ports:
>>> - IRIX
>>> - UnixWare
>>> - Tru64
>>
>> According to http://en.wikip
On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch wrote:
> Removing support for alpha is a different animal compared to removing support
> for non-gcc MIPS and most of the others in your list. A hacker wishing to
> restore support for another MIPS compiler would fill in the assembly code
> blanks, pro
On Wed, Oct 16, 2013 at 10:04:29PM +0200, Andres Freund wrote:
> On 2013-10-16 15:49:54 -0400, Bruce Momjian wrote:
> > On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
> > > > - ALPHA (big pain in the ass to get right, nobody uses it anymore)
> > >
> > > Yes, for many years now AL
On 2013-10-16 16:10:18 -0400, Robert Haas wrote:
> (though I don't see the code you're talking about wrt/32bit sparc)
< v9 sparc doesn't support compare-and-swap like operations, that's the
background.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
On 2013-10-16 16:10:18 -0400, Robert Haas wrote:
> On the other hand, I'm not convinced that we don't need to give any
> thought to UNIX vendors that are still pushing their proprietary
> compilers. Many of the old players are dead, but IBM's ICC and HP's
> aCC definitely aren't, and I wouldn't be
On Wed, Oct 16, 2013 at 3:26 PM, Andres Freund wrote:
>> I don't agree with that policy. Sure, 97% of our users are probably
>> running Linux, Windows, MacOS X, or one of the fairly-popular BSD
>> variants. But I think a part of the appeal of PostgreSQL is that it is
>> cross-platform, and doesn'
On 2013-10-16 15:49:54 -0400, Bruce Momjian wrote:
> On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
> > > - ALPHA (big pain in the ass to get right, nobody uses it anymore)
> >
> > Yes, for many years now ALPHA has only been useful as a way of
> > illustrating how bad it's possib
On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
> > - ALPHA (big pain in the ass to get right, nobody uses it anymore)
>
> Yes, for many years now ALPHA has only been useful as a way of
> illustrating how bad it's possible for CPU memory operation reordering
> considerations to ge
On Wed, Oct 16, 2013 at 1:52 PM, Andres Freund wrote:
> On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
>> So I vote for removing IRIX and Tru64 immediately, but I'm a little
>> more hesitant about shooting UnixWare, since it's technically still
>> supported.
>
> I think if somebody wants to have
On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
> > - m86k (doesn't have a useable CAS on later iterations like coldfire)
>
> I don't think we can desupport it just because it doesn't have CAS.
Btw, if necessary we could easily support the pre coldfire
variants. Note that e.g. debian doesn't sup
On 2013-10-16 13:55:20 -0400, Robert Haas wrote:
> >> - sinix (s_lock support remaining)
> >> - sun3 (I think it's just s_lock support remaining)
> >> - natsemi 32k
>
> Patch removing spinlock support for these three ports is attached.
> This is not to say we couldn't remove more later, but these
>> - sinix (s_lock support remaining)
>> - sun3 (I think it's just s_lock support remaining)
>> - natsemi 32k
Patch removing spinlock support for these three ports is attached.
This is not to say we couldn't remove more later, but these seem to be
the three spinlock implementations that are most s
On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
> So I vote for removing IRIX and Tru64 immediately, but I'm a little
> more hesitant about shooting UnixWare, since it's technically still
> supported.
I think if somebody wants to have it supported they need to provide a
buildfarm member and proba
On 10/16/2013 07:04 PM, Robert Haas wrote:
> On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund wrote:
>> I think we should remove support the following ports:
>> - IRIX
>> - UnixWare
>> - Tru64
>
> According to http://en.wikipedia.org/wiki/IRIX, IRIX has been
> officially retired. The last release
On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund wrote:
> I think we should remove support the following ports:
> - IRIX
> - UnixWare
> - Tru64
According to http://en.wikipedia.org/wiki/IRIX, IRIX has been
officially retired. The last release of IRIX was in 2006 and support
will end in December of
On 2013-10-16 12:26:28 -0400, Robert Haas wrote:
> On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund wrote:
> > On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
> >> More to the point for this specific case, it seems like our process
> >> ought to be
> >> (1) select a preferably-small set of gcc atomic
On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund wrote:
> On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
>> More to the point for this specific case, it seems like our process
>> ought to be
>> (1) select a preferably-small set of gcc atomic intrinsics that we
>> want to use.
>
> I suggest:
> * pg_at
On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
> More to the point for this specific case, it seems like our process
> ought to be
> (1) select a preferably-small set of gcc atomic intrinsics that we
> want to use.
I suggest:
* pg_atomic_load_u32(uint32 *)
* uint32 pg_atomic_store_u32(uint32 *)
* u
On 2013-10-14 09:42:46 -0400, Robert Haas wrote:
> On Mon, Oct 14, 2013 at 9:41 AM, Andres Freund wrote:
> > On 2013-10-14 09:40:10 -0400, Robert Haas wrote:
> >> On Sun, Oct 13, 2013 at 5:34 AM, Tom Lane wrote:
> >> >> - PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.
> >> >
On Mon, Oct 14, 2013 at 9:41 AM, Andres Freund wrote:
> On 2013-10-14 09:40:10 -0400, Robert Haas wrote:
>> On Sun, Oct 13, 2013 at 5:34 AM, Tom Lane wrote:
>> >> - PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.
>> >
>> > Until pretty recently, there was a PA-RISC machine (no
On 2013-10-14 09:40:10 -0400, Robert Haas wrote:
> On Sun, Oct 13, 2013 at 5:34 AM, Tom Lane wrote:
> >> - PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.
> >
> > Until pretty recently, there was a PA-RISC machine (not mine) in the
> > buildfarm. I don't see it in the list tod
On Sun, Oct 13, 2013 at 5:34 AM, Tom Lane wrote:
>> - PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.
>
> Until pretty recently, there was a PA-RISC machine (not mine) in the
> buildfarm. I don't see it in the list today though. In any case,
> HP's compiler has always been a
On 2013-10-13 20:39:21 +0200, Tom Lane wrote:
> Andres Freund writes:
> > The question about platforms that simply cannot provide such atomics
> > like PA-RISC, which afaics is the only one, remains tho. I am not sure
> > we really want to provide codepaths that are only going to be tested
> > the
Andres Freund writes:
> The question about platforms that simply cannot provide such atomics
> like PA-RISC, which afaics is the only one, remains tho. I am not sure
> we really want to provide codepaths that are only going to be tested
> there.
PA-RISC is a dead architecture. According to wikip
On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
> Andres Freund writes:
> > That's a fair point. But all of them will use gcc, right? I've
> > previously thought we'd need 4.4 because there's an incompatibility
> > between 4.3 and 4.4 but I think it won't touch us, so 4.2 which added
> > atomics for
Andres Freund writes:
> That's a fair point. But all of them will use gcc, right? I've
> previously thought we'd need 4.4 because there's an incompatibility
> between 4.3 and 4.4 but I think it won't touch us, so 4.2 which added
> atomics for mips seems fine. Given there's no buildfarm animal and
On 2013-10-13 14:08:59 +0200, Andres Freund wrote:
> On 2013-10-13 11:34:42 +0200, Tom Lane wrote:
> > Andres Freund writes:
> > > I think we should remove support for the following architectures:
> > > - superH
> >
> > This one was contributed just a year or two ago, if memory serves,
> > which
On 2013-10-13 11:34:42 +0200, Tom Lane wrote:
> Andres Freund writes:
> > I think we should remove support for the following architectures:
> > - superH
>
> This one was contributed just a year or two ago, if memory serves,
> which suggests that somebody out there cares about it. OTOH, if
> they
On 2013-10-12 18:35:00 -0700, Peter Geoghegan wrote:
> Not so sure about these.
> > - M32R (no userspace CAS afaics)
I don't think M32R will hurt us/anybody much.
> > - 32bit/ > - mips for anything but gcc > 4.4, using gcc's atomics support
The reason I'd like to de-support mips for older GCCs i
Andres Freund writes:
> I think we should remove support for the following architectures:
> - superH
This one was contributed just a year or two ago, if memory serves,
which suggests that somebody out there cares about it. OTOH, if
they still care, we could insist they provide whatever atomic op
On Sat, Oct 12, 2013 at 5:46 PM, Andres Freund wrote:
> I think we should remove support the following ports:
> - IRIX
> - UnixWare
> - Tru64
>
> Neither of those are relevant.
Seems reasonable.
> I think we should remove support for the following architectures:
> - VAX
Agreed.
> - univel (s_l
Hi,
As discussed in 20130926225545.gb26...@awork2.anarazel.de and on quite
some other occasions there's quite some scalability improvements we
could make if we had cross platform support for atomic
operations. Providing that is a fair bit of work for every
architecture/compiler/OS, so I think it's
44 matches
Mail list logo
