remove dead ports?

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@gmx.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@gmail.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@gmail.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@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.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@gmail.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@momjian.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@momjian.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@momjian.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@momjian.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@momjian.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@gmx.net> wrote:

On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:

On 3 May 2012 17:21, Bruce Momjian <bruce@momjian.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@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce@momjian.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@momjian.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@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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