Re: remove dead ports?

I propose that we remove support for the following OS ports from our
source tree. They are totally dead, definitely don't work, and/or
probably no one remembers what they even were. The code just bit rots
and is in the way of future improvements.

* Dead/remove:

dgux
nextstep
sunos4
svr4
ultrix4
univel

* Dubious, but keep for now:

bsdi
irix
osf
sco

* No concern:

aix
cygwin
darwin
freebsd
hpux
linux
netbsd
openbsd
solaris
unixware
win32

On 04/24/2012 08:29 PM, Peter Eisentraut wrote:
> I propose that we remove support for the following OS ports from our
> source tree. They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were. The code just bit rots
> and is in the way of future improvements.
>
> * Dead/remove:
>
> dgux
> nextstep
> sunos4
> svr4
> ultrix4
> univel

+1

>
> * Dubious, but keep for now:
>
> bsdi
> irix
> osf
> sco

I'm pretty sure I have seen at least semi recent reports of users on at
least irix and sco, for the rest of them I think bruce recently stopped
using bsdi so the only ever known user of that platform is gone...

Stefan

On Tue, Apr 24, 2012 at 2:29 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> I propose that we remove support for the following OS ports from our
> source tree.  They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were.  The code just bit rots
> and is in the way of future improvements.

I have no position on whether those operating systems are dead enough
to warrant removing support, but on a related point, I would like it
if we could get rid of as many spinlock implementations as are
applicable only to platforms that are effectively defunct. I'm
suspicious of s_lock.h's support for National Semiconductor 32K,
Renesas' M32R, Renesas' SuperH, UNIVEL, SINIX / Reliant UNIX,
Nextstep, and Sun3, all of which are either on your list above, or
stuff I've never heard of. I have no problem keeping whatever people
are still using, but it would be nice to eliminate anything that's
actually dead for the reasons you state.

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

On Tue, Apr 24, 2012 at 9:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>  I'm
> suspicious of s_lock.h's support for National Semiconductor 32K,
> Renesas' M32R, Renesas' SuperH, UNIVEL, SINIX / Reliant UNIX,
> Nextstep, and Sun3

Were there ever multiprocessor Nextstep or Sun3 machines anyways?
Wouldn't someone on these OSes want spinlocks to immediately sleep
anyways?

I did experiment a while back with getting a vax emulator going to
build postgres on it but even then I was running NetBSD.

--
greg

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I have no position on whether those operating systems are dead enough
> to warrant removing support, but on a related point, I would like it
> if we could get rid of as many spinlock implementations as are
> applicable only to platforms that are effectively defunct. I'm
> suspicious of s_lock.h's support for National Semiconductor 32K,
> Renesas' M32R, Renesas' SuperH, UNIVEL, SINIX / Reliant UNIX,
> Nextstep, and Sun3, all of which are either on your list above, or
> stuff I've never heard of. I have no problem keeping whatever people
> are still using, but it would be nice to eliminate anything that's
> actually dead for the reasons you state.

The Renesas implementations were added pretty darn recently, so I think
there are users for those. The others you mention seem dead to me.
On the other hand, exactly how much is it costing us to leave those
sections of s_lock.h in there? It's not like we have any plans to
redefine the spinlock interfaces.

regards, tom lane

On Wed, Apr 25, 2012 at 12:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I have no position on whether those operating systems are dead enough
>> to warrant removing support, but on a related point, I would like it
>> if we could get rid of as many spinlock implementations as are
>> applicable only to platforms that are effectively defunct.  I'm
>> suspicious of s_lock.h's support for National Semiconductor 32K,
>> Renesas' M32R, Renesas' SuperH, UNIVEL, SINIX / Reliant UNIX,
>> Nextstep, and Sun3, all of which are either on your list above, or
>> stuff I've never heard of.  I have no problem keeping whatever people
>> are still using, but it would be nice to eliminate anything that's
>> actually dead for the reasons you state.
>
> The Renesas implementations were added pretty darn recently, so I think
> there are users for those.  The others you mention seem dead to me.
> On the other hand, exactly how much is it costing us to leave those
> sections of s_lock.h in there?  It's not like we have any plans to
> redefine the spinlock interfaces.

Well, actually, one thing I would like to do is add
SpinLockConditionalAcquire(). I haven't quite found a compelling
argument for having it yet, but it keeps coming up as I noodle around
with different techniques to improve concurrency. I think there are
some other things we'll want to add eventually, too. Of course none
of that is impossible even if we keep everything, but like Peter said
it saves work to not have to worry about ports that are completely
defunct. I don't feel super-strongly about it, but OTOH I see little
reason to keep the Univel spinlock implementation if we're removing
the Univel port. If we ever decide to resupport the platform we can
fish all the necessary bits out of git, and in fact it'll be easier if
a single commit removes all traces of support rather than having it
gradually disappear from the tree a bit at a time.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... I don't feel super-strongly about it, but OTOH I see little
> reason to keep the Univel spinlock implementation if we're removing
> the Univel port.

No, I have no objection to that. I was just questioning the wisdom of
removing CPU-specific s_lock sections on the grounds that we haven't
heard from any users of that CPU lately. Doesn't mean they are not
out there.

regards, tom lane

On Tue, Apr 24, 2012 at 09:29:39PM +0300, Peter Eisentraut wrote:
> I propose that we remove support for the following OS ports from our
> source tree. They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were. The code just bit rots
> and is in the way of future improvements.
>
> * Dead/remove:
>
> dgux
> nextstep
> sunos4
> svr4
> ultrix4
> univel
>
> * Dubious, but keep for now:
>
> bsdi

I am no longer on bsdi and I bet there are no more existing users
either. I can be removed, I think.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Tue, May 01, 2012 at 04:39:32PM -0400, Bruce Momjian wrote:
> On Tue, Apr 24, 2012 at 09:29:39PM +0300, Peter Eisentraut wrote:
> > I propose that we remove support for the following OS ports from our
> > source tree. They are totally dead, definitely don't work, and/or
> > probably no one remembers what they even were. The code just bit rots
> > and is in the way of future improvements.
> >
> > * Dead/remove:
> >
> > dgux
> > nextstep
> > sunos4
> > svr4
> > ultrix4
> > univel
> >
> > * Dubious, but keep for now:
> >
> > bsdi
>
> I am no longer on bsdi and I bet there are no more existing users
> either. It can be removed, I think.

Having received no replies on "general" from bsdi users considering
upgrading to 9.2, I have removed the port.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On tor, 2012-05-03 at 10:59 -0400, Bruce Momjian wrote:
> Having received no replies on "general" from bsdi users considering
> upgrading to 9.2, I have removed the port.

I think that was quite premature. There is no requirement that bsdi
users need to read pgsql-general, especially if you give them only a 24
hour notice. The bsdi port still appears to work, and it doesn't cost
us anything to maintain it, so I think we should keep it, or at least
have a longer grace period.

On Thu, May 03, 2012 at 07:11:47PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 10:59 -0400, Bruce Momjian wrote:
> > Having received no replies on "general" from bsdi users considering
> > upgrading to 9.2, I have removed the port.
>
> I think that was quite premature. There is no requirement that bsdi
> users need to read pgsql-general, especially if you give them only a 24
> hour notice. The bsdi port still appears to work, and it doesn't cost
> us anything to maintain it, so I think we should keep it, or at least
> have a longer grace period.

I think I was the only user left; I have never heard from a BSD/OS user
in the past 5-7 years. The last official release was in 2003/2004:

http://en.wikipedia.org/wiki/BSD/OS

I rather think I kept it a viable port on my own, and can't anymore.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On 3 May 2012 17:21, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I think I was the only user left;  I have never heard from a BSD/OS user
> in the past 5-7 years.

I'm inclined to agree with Bruce. While it's not reasonable to assume
that the lack of a BSD/OS user complaining on -general indicates that
there are none, it's also not reasonable for them to expect us to
support their operating system for 8 years after the original
proprietary vendor. Better to not support BSD/OS than to supply a port
that no one really has any confidence in. It's not as if we've ceased
support in release branches.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
> On 3 May 2012 17:21, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I think I was the only user left; I have never heard from a BSD/OS user
> > in the past 5-7 years.
>
> I'm inclined to agree with Bruce. While it's not reasonable to assume
> that the lack of a BSD/OS user complaining on -general indicates that
> there are none, it's also not reasonable for them to expect us to
> support their operating system for 8 years after the original
> proprietary vendor. Better to not support BSD/OS than to supply a port
> that no one really has any confidence in. It's not as if we've ceased
> support in release branches.

I'm not so much opposed to removing the port. I am more concerned about
the manner in which it was done. The other ports I removed were known
to not work anyway, for years, and there were at least several days of
discussion. The bsdi case was removing a working port with less than 24
hours notice.

On Fri, May 4, 2012 at 8:45 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
>> On 3 May 2012 17:21, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > I think I was the only user left;  I have never heard from a BSD/OS user
>> > in the past 5-7 years.
>>
>> I'm inclined to agree with Bruce. While it's not reasonable to assume
>> that the lack of a BSD/OS user complaining on -general indicates that
>> there are none, it's also not reasonable for them to expect us to
>> support their operating system for 8 years after the original
>> proprietary vendor. Better to not support BSD/OS than to supply a port
>> that no one really has any confidence in. It's not as if we've ceased
>> support in release branches.
>
> I'm not so much opposed to removing the port.  I am more concerned about
> the manner in which it was done.  The other ports I removed were known
> to not work anyway, for years, and there were at least several days of
> discussion.  The bsdi case was removing a working port with less than 24
> hours notice.

There is enough time until 9.2-final for a BSD/OS user raise complaints.

--
marko

On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
> > On 3 May 2012 17:21, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > I think I was the only user left; I have never heard from a BSD/OS user
> > > in the past 5-7 years.
> >
> > I'm inclined to agree with Bruce. While it's not reasonable to assume
> > that the lack of a BSD/OS user complaining on -general indicates that
> > there are none, it's also not reasonable for them to expect us to
> > support their operating system for 8 years after the original
> > proprietary vendor. Better to not support BSD/OS than to supply a port
> > that no one really has any confidence in. It's not as if we've ceased
> > support in release branches.
>
> I'm not so much opposed to removing the port. I am more concerned about
> the manner in which it was done. The other ports I removed were known
> to not work anyway, for years, and there were at least several days of
> discussion. The bsdi case was removing a working port with less than 24
> hours notice.

Not sure where you got 24 hours:

Tues http://archives.postgresql.org/pgsql-hackers/2012-05/msg00061.php
Wed http://archives.postgresql.org/pgsql-general/2012-05/msg00060.php
Thur http://archives.postgresql.org/pgsql-committers/2012-05/msg00023.php

Basically, we have beta next week so I wanted to do it before then, and
I have my head down doing the release notes, so I wanted to do it before
I started that too. I kind of knew the bsdi answer before I even asked.

If you are objecting to me short-circuiting this, I will revert the
patch. If we can't short-circuiting thinks when we already know the
answer, everyone's work will take more time.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
>> I'm not so much opposed to removing the port. I am more concerned about
>> the manner in which it was done. The other ports I removed were known
>> to not work anyway, for years, and there were at least several days of
>> discussion. The bsdi case was removing a working port with less than 24
>> hours notice.

What's the grounds for asserting they were known not to work? Not
actual testing, I assume.

> Basically, we have beta next week so I wanted to do it before then, and
> I have my head down doing the release notes, so I wanted to do it before
> I started that too. I kind of knew the bsdi answer before I even asked.

> If you are objecting to me short-circuiting this, I will revert the
> patch. If we can't short-circuiting thinks when we already know the
> answer, everyone's work will take more time.

Leave it as-is. I agree with the upthread comment that we can revert
the patch during beta (or even later than that), if anyone complains.
Furthermore, I would want to insist that a complainer provide a
buildfarm member as the price of us continuing to support an old
uncommon platform. Otherwise the apparent support is hollow. The BSDI
port was viable for us to support as long as Bruce was using it daily,
but with that gone, we need somebody else to be testing it.

regards, tom lane

On Fri, May 04, 2012 at 06:25:24PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
> >> I'm not so much opposed to removing the port. I am more concerned about
> >> the manner in which it was done. The other ports I removed were known
> >> to not work anyway, for years, and there were at least several days of
> >> discussion. The bsdi case was removing a working port with less than 24
> >> hours notice.
>
> What's the grounds for asserting they were known not to work? Not
> actual testing, I assume.
>
> > Basically, we have beta next week so I wanted to do it before then, and
> > I have my head down doing the release notes, so I wanted to do it before
> > I started that too. I kind of knew the bsdi answer before I even asked.
>
> > If you are objecting to me short-circuiting this, I will revert the
> > patch. If we can't short-circuiting thinks when we already know the
> > answer, everyone's work will take more time.
>
> Leave it as-is. I agree with the upthread comment that we can revert
> the patch during beta (or even later than that), if anyone complains.
> Furthermore, I would want to insist that a complainer provide a
> buildfarm member as the price of us continuing to support an old
> uncommon platform. Otherwise the apparent support is hollow. The BSDI
> port was viable for us to support as long as Bruce was using it daily,
> but with that gone, we need somebody else to be testing it.

Yes, it was an odd port that probably would have been removed five years
ago if I had not been using it, which I am no longer.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On fre, 2012-05-04 at 18:16 -0400, Bruce Momjian wrote:
> Not sure where you got 24 hours:
>
> Tues http://archives.postgresql.org/pgsql-hackers/2012-05/msg00061.php
> Wed http://archives.postgresql.org/pgsql-general/2012-05/msg00060.php
> Thur http://archives.postgresql.org/pgsql-committers/2012-05/msg00023.php

The time between the post to -general and the commit.

On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> What's the grounds for asserting they were known not to work? Not
> actual testing, I assume.

There were either essential pieces missing (e.g., no shared library
support, or no Makefile.port), or we had received reports in the past
the platform doesn't work and won't be fixed anymore by the original
supporter.

> Furthermore, I would want to insist that a complainer provide a
> buildfarm member as the price of us continuing to support an old
> uncommon platform. Otherwise the apparent support is hollow. The BSDI
> port was viable for us to support as long as Bruce was using it daily,
> but with that gone, we need somebody else to be testing it.

Based on these emerging criteria, should we also remove the other
platforms on my original "marginal" list?

irix
osf
sco

irix and osf support was already dropped in Python 3.0, so probably
their time is up.

On Sat, May 05, 2012 at 11:59:54AM +0300, Peter Eisentraut wrote:
> On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> > What's the grounds for asserting they were known not to work? Not
> > actual testing, I assume.
>
> There were either essential pieces missing (e.g., no shared library
> support, or no Makefile.port), or we had received reports in the past
> the platform doesn't work and won't be fixed anymore by the original
> supporter.
>
> > Furthermore, I would want to insist that a complainer provide a
> > buildfarm member as the price of us continuing to support an old
> > uncommon platform. Otherwise the apparent support is hollow. The BSDI
> > port was viable for us to support as long as Bruce was using it daily,
> > but with that gone, we need somebody else to be testing it.
>
> Based on these emerging criteria, should we also remove the other
> platforms on my original "marginal" list?
>
> irix
> osf
> sco
>
> irix and osf support was already dropped in Python 3.0, so probably
> their time is up.

Good question. SCO seems risky, but irix and osf are very possible. I
would ask about all three on general. You probably have to give it more
time because we don't know as much about the usage as we did about bsdi.
We have to wrap this up before beta so it will be tight.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
>> Furthermore, I would want to insist that a complainer provide a
>> buildfarm member as the price of us continuing to support an old
>> uncommon platform. Otherwise the apparent support is hollow. The BSDI
>> port was viable for us to support as long as Bruce was using it daily,
>> but with that gone, we need somebody else to be testing it.

> Based on these emerging criteria, should we also remove the other
> platforms on my original "marginal" list?

> irix
> osf
> sco

Possibly. What exactly is the difference between the "sco" and
"unixware" ports, anyway? The one buildfarm member we have running
SCO software (koi) chooses the unixware template.

> irix and osf support was already dropped in Python 3.0, so probably
> their time is up.

Yeah, been a long time since I heard of either.

regards, tom lane

On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> >> Furthermore, I would want to insist that a complainer provide a
> >> buildfarm member as the price of us continuing to support an old
> >> uncommon platform. Otherwise the apparent support is hollow. The BSDI
> >> port was viable for us to support as long as Bruce was using it daily,
> >> but with that gone, we need somebody else to be testing it.
>
> > Based on these emerging criteria, should we also remove the other
> > platforms on my original "marginal" list?
>
> > irix
> > osf
> > sco
>
> Possibly. What exactly is the difference between the "sco" and
> "unixware" ports, anyway? The one buildfarm member we have running
> SCO software (koi) chooses the unixware template.

Unixware was based on Unix System Labs System V, Release 4, while SCO
was based on a 286 port of SVr2, or something like that. Both were
produced by SCO, though Novell was also involved with it:

http://en.wikipedia.org/wiki/UnixWare

> > irix and osf support was already dropped in Python 3.0, so probably
> > their time is up.
>
> Yeah, been a long time since I heard of either.

Yep.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
>> Possibly. What exactly is the difference between the "sco" and
>> "unixware" ports, anyway? The one buildfarm member we have running
>> SCO software (koi) chooses the unixware template.

> Unixware was based on Unix System Labs System V, Release 4, while SCO
> was based on a 286 port of SVr2, or something like that.

Oh, so the "sco" port actually refers to OpenServer?

http://en.wikipedia.org/wiki/SCO_OpenServer

That page makes it sound like it's more or less as current as Unixware,
since both had their last updates in 2008/2009 timeframe (and both
are presumably never going to see another one, with SCO the company
being dead in all but name).

The difference from our perspective is that we have a buildfarm member
running Unixware, whereas it's anybody's guess whether the "sco" port
still works or not.

regards, tom lane

On 5 May 2012 09:59, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Based on these emerging criteria, should we also remove the other
> platforms on my original "marginal" list?
>
> irix

Well, there hasn't been an IRIX release since 2006, and silicon
graphics is defunct. The SGI brand lives on, though I think that that
organisation isn't in any meaningful sense a successor - certainly,
they don't produce the IRIX workstations (or any other) that were the
main business of SGI for so long.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> >> Possibly. What exactly is the difference between the "sco" and
> >> "unixware" ports, anyway? The one buildfarm member we have running
> >> SCO software (koi) chooses the unixware template.
>
> > Unixware was based on Unix System Labs System V, Release 4, while SCO
> > was based on a 286 port of SVr2, or something like that.
>
> Oh, so the "sco" port actually refers to OpenServer?
>
> http://en.wikipedia.org/wiki/SCO_OpenServer
>
> That page makes it sound like it's more or less as current as Unixware,
> since both had their last updates in 2008/2009 timeframe (and both
> are presumably never going to see another one, with SCO the company
> being dead in all but name).
>
> The difference from our perspective is that we have a buildfarm member
> running Unixware, whereas it's anybody's guess whether the "sco" port
> still works or not.

Yes, sorry, I should have been clearer. SCO is both an OS and a
company. The 'sco' references OpenServer.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> >> Possibly. What exactly is the difference between the "sco" and
> >> "unixware" ports, anyway? The one buildfarm member we have running
> >> SCO software (koi) chooses the unixware template.
>
> > Unixware was based on Unix System Labs System V, Release 4, while SCO
> > was based on a 286 port of SVr2, or something like that.
>
> Oh, so the "sco" port actually refers to OpenServer?
>
> http://en.wikipedia.org/wiki/SCO_OpenServer
>
> That page makes it sound like it's more or less as current as Unixware,
> since both had their last updates in 2008/2009 timeframe (and both
> are presumably never going to see another one, with SCO the company
> being dead in all but name).
>
> The difference from our perspective is that we have a buildfarm member
> running Unixware, whereas it's anybody's guess whether the "sco" port
> still works or not.

Well, absent user feedback, we could use our own 5-year rule and keep
sco and unixware, and remove irix (2006).

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Well, absent user feedback, we could use our own 5-year rule and keep
> sco and unixware, and remove irix (2006).

I think we should err on the side of removing less rather than more.
It won't hurt anything much to leave these around for another few
years.

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

On 6 May 2012 01:06, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Well, absent user feedback, we could use our own 5-year rule and keep
>> sco and unixware, and remove irix (2006).
>
> I think we should err on the side of removing less rather than more.
> It won't hurt anything much to leave these around for another few
> years.

I think it's better to force users of platforms like IRIX and BSD/OS,
platforms which are obsolete according to any practical definition, to
use earlier branches that presumably are known to have had a certain
amount of testing. Supporting these platforms while "flying blind"
seems to rather devalue what it means for a platform to be supported
by Postgres. Presumably these users don't plan to stay on their
platform of choice forever, and don't have terribly demanding needs,
so I don't really see that we're doing them any kind of disservice.
Continuing to support these platforms is actually the less
conservative option.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 6 May 2012 01:06, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I think we should err on the side of removing less rather than more.
>> It won't hurt anything much to leave these around for another few
>> years.

> I think it's better to force users of platforms like IRIX and BSD/OS,
> platforms which are obsolete according to any practical definition, to
> use earlier branches that presumably are known to have had a certain
> amount of testing.

If there are any such users, we should be trying to get them to provide
a buildfarm member, so that we can honestly say that the port works.
I see removal of the port files as a way to send an unmistakable signal
that we're not going to continue to guess about that. We can always put
back a given port if volunteers emerge to support it.

regards, tom lane

On 6 May 2012 15:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> On 6 May 2012 01:06, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I think we should err on the side of removing less rather than more.
>>> It won't hurt anything much to leave these around for another few
>>> years.
>
>> I think it's better to force users of platforms like IRIX and BSD/OS,
>> platforms which are obsolete according to any practical definition, to
>> use earlier branches that presumably are known to have had a certain
>> amount of testing.
>
> If there are any such users, we should be trying to get them to provide
> a buildfarm member, so that we can honestly say that the port works.
> I see removal of the port files as a way to send an unmistakable signal
> that we're not going to continue to guess about that. We can always put
> back a given port if volunteers emerge to support it.

About 3 years ago I tried to get a loan machine running IRIX, given
that I used to have an SGI O2 for data visualisation work about a
decade ago.
I couldn't get through to anybody or even raise interest.

Agree with comments upthread, if you run IRIX you can use earlier
versions of Postgres that support it.

SGI support for IRIX ends in Dec 2013, following on from
discontinuation of hardware in 2006/7
http://www.sgi.com/services/support/irix_mips_support.html

Which means 9.3 will not have an IRIX platform to run on for more than
a few months after release, so I think we should remove IRIX support
now.

SGI themselves ship Red Hat or SUSE now anyway
http://en.wikipedia.org/wiki/IRIX

Any objections to removing irix support now?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Thu, Sep 13, 2012 at 10:00:51AM +0100, Simon Riggs wrote:
> SGI support for IRIX ends in Dec 2013, following on from
> discontinuation of hardware in 2006/7
> http://www.sgi.com/services/support/irix_mips_support.html
>
> Which means 9.3 will not have an IRIX platform to run on for more than
> a few months after release, so I think we should remove IRIX support
> now.

> Any objections to removing irix support now?

While I wouldn't personally weep for its loss, I think it's premature. The
others Peter Eisentraut removed have been in the ground about a decade longer
than IRIX. In the absence of a specific reason to believe PostgreSQL no
longer works on the platform or a notable maintenance benefit from removing
its platform-specific source code, let's keep it awhile.

On 13 September 2012 14:18, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Thu, Sep 13, 2012 at 10:00:51AM +0100, Simon Riggs wrote:
>> SGI support for IRIX ends in Dec 2013, following on from
>> discontinuation of hardware in 2006/7
>> http://www.sgi.com/services/support/irix_mips_support.html
>>
>> Which means 9.3 will not have an IRIX platform to run on for more than
>> a few months after release, so I think we should remove IRIX support
>> now.
>
>> Any objections to removing irix support now?
>
> While I wouldn't personally weep for its loss, I think it's premature. The
> others Peter Eisentraut removed have been in the ground about a decade longer
> than IRIX. In the absence of a specific reason to believe PostgreSQL no
> longer works on the platform or a notable maintenance benefit from removing
> its platform-specific source code, let's keep it awhile.

I agree.

I think we need an in-between status of
might-work-will-remove-if-it-doesnt. The key is not whether to remove
it, the key is whether the lack of support for certain features in an
old OS is sufficient to prevent forward progress of PostgreSQL.

IMHO, IRIX no longer rates extra effort, should it be required.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Thu, Sep 13, 2012 at 02:29:08PM +0100, Simon Riggs wrote:
> I think we need an in-between status of
> might-work-will-remove-if-it-doesnt. The key is not whether to remove
> it, the key is whether the lack of support for certain features in an
> old OS is sufficient to prevent forward progress of PostgreSQL.
>
> IMHO, IRIX no longer rates extra effort, should it be required.

+1 for that.