Re: Predicted lifespan of different PostgreSQL branches

I spend some time googling this and searching the Postgresql.org site, but
I'm either not good enough with the search strings, or it's not to be found.

I'm trying to plan upgrades so that we don't upgrade needlessly, but also
don't get caught using stuff that nobody's supporting any more.
The FreeBSD project keeps this schedule:
http://www.freebsd.org/security/#adv
which is _really_ nice when talking to managers and similar people about
when upgrades need to be scheduled.

Does the PostgreSQL project have any similar policy about EoLs? Even just
a simple statement like, "it is our goal to support major branches for 2
years after release" or some such?

--
Bill Moran
Collaborative Fusion Inc.

Bill Moran wrote:
> I spend some time googling this and searching the Postgresql.org site, but
> I'm either not good enough with the search strings, or it's not to be found.
>
> I'm trying to plan upgrades so that we don't upgrade needlessly, but also
> don't get caught using stuff that nobody's supporting any more.
> The FreeBSD project keeps this schedule:
> http://www.freebsd.org/security/#adv
> which is _really_ nice when talking to managers and similar people about
> when upgrades need to be scheduled.
>
> Does the PostgreSQL project have any similar policy about EoLs? Even just
> a simple statement like, "it is our goal to support major branches for 2
> years after release" or some such?
>

There is no set time frame planned that I know of.

It is more a matter of users that keep the old versions alive. Some with
large datasets on busy servers that can't allocate enough downtime to
upgrade tend to be keeping the older versions running.

As far as I know there are some companies that support the security
fixes being back-ported to 7.x releases and this is the only reason they
do get updates and are still listed on the site. There is some developer
desire to drop 7.x altogether.

v8.0 has been available for 2 years now and a common first answer to
support questions for anything older is to upgrade.
If they are running PostgreSQL on Windows then they should be using 8.1
at least and be encouraged to stay more up to date as the Windows
version is still young and less tested and is getting more improvements
with each release.

I would not suggest that you have any clients use less than 8.0 with 8.1
preferred and 8.2 for new installs.

But as the old saying goes if it ain't broke don't fix it. If the
version they have runs fine and fulfills their need then leave it be.

Upgrading at the same time as hardware can be a good way to go if you
aren't interested in always having the newest version.

--

Shane Ambler
pgSQL(at)007Marketing(dot)com

Get Sheeky @ http://Sheeky.Biz

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/07 17:28, Shane Ambler wrote:
> Bill Moran wrote:
>> I spend some time googling this and searching the Postgresql.org site,
>> but
>> I'm either not good enough with the search strings, or it's not to be
>> found.
>>
>> I'm trying to plan upgrades so that we don't upgrade needlessly, but also
>> don't get caught using stuff that nobody's supporting any more.
>> The FreeBSD project keeps this schedule:
>> http://www.freebsd.org/security/#adv
>> which is _really_ nice when talking to managers and similar people about
>> when upgrades need to be scheduled.
>>
>> Does the PostgreSQL project have any similar policy about EoLs? Even
>> just
>> a simple statement like, "it is our goal to support major branches for 2
>> years after release" or some such?
>>
>
> There is no set time frame planned that I know of.
>
> It is more a matter of users that keep the old versions alive. Some with
> large datasets on busy servers that can't allocate enough downtime to
> upgrade tend to be keeping the older versions running.

How much does the on-disk structure of *existing* tables and indexes
change between x.y versions?

Between, for example, 8.0 and 8.2?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFupB8S9HxQb37XmcRArvWAKCwTj6kDG6+rAa4vZ30PEQUkDHy5ACg7CZf
8PaPJuy6gYBuCo5JNdxgdBQ=
=olUx
-----END PGP SIGNATURE-----

Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:

> How much does the on-disk structure of *existing* tables and indexes
> change between x.y versions?
>
> Between, for example, 8.0 and 8.2?

Enough to require a dump/reload in order to upgrade. :)

Within major versions (8.2.0, 8.2.1, etc) the files are compatible so
you can do in-place upgrades (except in extraordinary circumstances).

-Doug

Ron Johnson wrote:
> > There is no set time frame planned that I know of.
> >
> > It is more a matter of users that keep the old versions alive. Some with
> > large datasets on busy servers that can't allocate enough downtime to
> > upgrade tend to be keeping the older versions running.
>
> How much does the on-disk structure of *existing* tables and indexes
> change between x.y versions?
>
> Between, for example, 8.0 and 8.2?

Yes:

http://www.postgresql.org/docs/8.2/static/migration.html

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

+ If your life is a hard drive, Christ can be your backup. +

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/07 20:12, Bruce Momjian wrote:
> Ron Johnson wrote:
>>> There is no set time frame planned that I know of.
>>>
>>> It is more a matter of users that keep the old versions alive. Some with
>>> large datasets on busy servers that can't allocate enough downtime to
>>> upgrade tend to be keeping the older versions running.
>>
>> How much does the on-disk structure of *existing* tables and indexes
>> change between x.y versions?
>>
>> Between, for example, 8.0 and 8.2?
>
> Yes:
>
> http://www.postgresql.org/docs/8.2/static/migration.html

I was thinking of something like the release notes, but a bit more
targeted. (I know. diff the source.)

http://www.postgresql.org/docs/8.2/interactive/release-8-2.html

For example, I've read these release notes, and there are some index
modifications, but don't *seem* to be *table* structure changes.

So, in an upgrade from 8.1 to 8.2, what's really preventing pg from
letting the user:

1. Cleanly shutdown pg.
2. Install v8.2.
3. Start pg.
4. psql -c 'REINDEX DATABASE' some_db

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFuslLS9HxQb37XmcRAn90AJ4zCgRqXZbXMmWKTXWT1o7Y2c7S8ACgxYcD
maKk5w+qam1Uy8SDi/R0WQ4=
=UHLl
-----END PGP SIGNATURE-----

Ron Johnson wrote:
> > Yes:
> >
> > http://www.postgresql.org/docs/8.2/static/migration.html
>
> I was thinking of something like the release notes, but a bit more
> targeted. (I know. diff the source.)
>
> http://www.postgresql.org/docs/8.2/interactive/release-8-2.html
>
> For example, I've read these release notes, and there are some index
> modifications, but don't *seem* to be *table* structure changes.
>
> So, in an upgrade from 8.1 to 8.2, what's really preventing pg from
> letting the user:
>
> 1. Cleanly shutdown pg.
> 2. Install v8.2.
> 3. Start pg.
> 4. psql -c 'REINDEX DATABASE' some_db

The changes are usually very subtle, like changes in the storage format
for certain data types, or bit changes in the row headers --- it isn't
something really of interest except to developers.

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

+ If your life is a hard drive, Christ can be your backup. +

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/07 21:48, Bruce Momjian wrote:
> Ron Johnson wrote:
>>> Yes:
>>>
>>> http://www.postgresql.org/docs/8.2/static/migration.html
>> I was thinking of something like the release notes, but a bit more
>> targeted. (I know. diff the source.)
>>
>> http://www.postgresql.org/docs/8.2/interactive/release-8-2.html
>>
>> For example, I've read these release notes, and there are some index
>> modifications, but don't *seem* to be *table* structure changes.
>>
>> So, in an upgrade from 8.1 to 8.2, what's really preventing pg from
>> letting the user:
>>
>> 1. Cleanly shutdown pg.
>> 2. Install v8.2.
>> 3. Start pg.
>> 4. psql -c 'REINDEX DATABASE' some_db
>
> The changes are usually very subtle, like changes in the storage format
> for certain data types, or bit changes in the row headers --- it isn't
> something really of interest except to developers.

Ah, too low-level to make it into the relnotes.

What are your plans for reducing the number of resources needed to
upgrade databases?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFutInS9HxQb37XmcRAsihAKC+j6D4HVkWqc4l9EctRuHfud0WDgCghGZ6
a2W1ym+Fru3YowebTLgCqto=
=+K4E
-----END PGP SIGNATURE-----

>>>> 1. Cleanly shutdown pg.
>>>> 2. Install v8.2.
>>>> 3. Start pg.
>>>> 4. psql -c 'REINDEX DATABASE' some_db
>>> The changes are usually very subtle, like changes in the storage format
>>> for certain data types, or bit changes in the row headers --- it isn't
>>> something really of interest except to developers.
>
> Ah, too low-level to make it into the relnotes.
>
> What are your plans for reducing the number of resources needed to
> upgrade databases?

There will be a time, some time in the future that in place upgrades
will be available. In fact there was very little changes that made it
necessary from 8.1 to 8.2.

However, that being said, the best way to get it done is to either start
a project to do it, join a project to do it, or help sponsor a project
to do it.

The reality is, as much as a few like to shout that it is something that
must happen (in place upgrades) it is amazing how little work happens
from those people to have it happen.

Please note that I am not speaking about you directly, just that I find
that if something needs to happen, it will. In place upgrades hasn't
happen yet.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Fri, Jan 26, 2007 at 10:16:39PM -0600, Ron Johnson wrote:
> What are your plans for reducing the number of resources needed to
> upgrade databases?

As noted, the table structure changes only slightly between versions,
if at all. What does change significantly is the catalog. Even now
there have been significant underlying changes to make the catalog
totally incompatable. There has been work on a pg_upgrade tool which
would create a new database with the new version and then copy the data
tables from the old version and rebuild the indexes. The idea being
that the data is large, but the underlying system is fairly small.

In theory it could work, but I don't know about the status. There has
been some support from the core that *if* such a pg_upgrade tool
existed, *then* they would provide some backward compatability for he
datatypes.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Shane Ambler <pgsql(at)007Marketing(dot)com> writes:
> Bill Moran wrote:
>> Does the PostgreSQL project have any similar policy about EoLs?

> There is no set time frame planned that I know of.

No, there's no agreed-on policy. So far there's really only been one
release that we've actively decided to decommission, and that was 7.2.
Before about 7.1 or 7.2, to be frank, the code base was not solid enough
that anyone would expect long-term support; nor did we have the manpower
to consider back-patching any more than the latest release version.
So it was simply not a consideration before that. We dropped 7.2 when
we decided it was unfixably broken --- I don't recall the specific
motivation anymore, but it was a we-can't-fix-this-without-initdb kind
of problem, and if you're gonna initdb you might as well move to a newer
release branch.

> It is more a matter of users that keep the old versions alive.

Even more to the point, a matter of developers being willing to take
the time to ensure that critical fixes are back-ported to old branches.
Right now I think the driving force here is that Red Hat is paying me
to make critical fixes for versions that are in their supported RHEL
releases, namely PG 7.3 and 7.4. The EOLs for those RHEL versions are
still depressingly far away :-(. The rest of core does not care at all
about 7.x, but they're willing to humor me to the extent of wrapping
tarballs as long as I keep putting the bug fixes into CVS.

There's been some idle discussion on the lists about establishing an
official project policy, perhaps "five years from release", but I don't
see that as meaning anything, because in the end this is still all
driven by developers scratching their own itch (or their company's itch).
Way-back releases are going to get supported for exactly as long as
someone's willing to do the work. And future occurrences of the 7.2
"this is unfixable" decision are certainly not impossible, and would
throw a monkey wrench into any such plan anyway.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/07 00:19, Martijn van Oosterhout wrote:
> On Fri, Jan 26, 2007 at 10:16:39PM -0600, Ron Johnson wrote:
>> What are your plans for reducing the number of resources needed to
>> upgrade databases?
>
> As noted, the table structure changes only slightly between versions,
> if at all. What does change significantly is the catalog. Even now
> there have been significant underlying changes to make the catalog
> totally incompatable. There has been work on a pg_upgrade tool which
> would create a new database with the new version and then copy the data
> tables from the old version and rebuild the indexes. The idea being
> that the data is large, but the underlying system is fairly small.

You mean "copy just the system catalog"?

> In theory it could work, but I don't know about the status. There has
> been some support from the core that *if* such a pg_upgrade tool
> existed, *then* they would provide some backward compatability for he
> datatypes.

That's how the system I use at work does upgrades. The existing
user data formats don't change, but the system catalog does. So,
when you convert a DB, it makes a fresh copy of the catalog, and
then migrates the old catalog to the new catalog. 15 year old
systems can be upgraded that way, with no harm to the user data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFuvFGS9HxQb37XmcRAmyhAJ9bTG8cVB1vYk8YMWDeIXTuC49QXQCgqOAe
zzqCCBcZn9UdddvJKKw4vYM=
=3mVM
-----END PGP SIGNATURE-----

Bill Moran wrote:
> Does the PostgreSQL project have any similar policy about EoLs? Even just
> a simple statement like, "it is our goal to support major branches for 2
> years after release" or some such?

I've been considering only maintaining the current and previous 2
versions in pgInstaller (the Windows binary distro). But that's a *lot*
harder to maintain than just PostgreSQL because of all the bundled
stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.

What do people think about that? Does anyone think it would be an
unreasonable policy?

Regards, Dave

Hi,

On Sat, 2007-01-27 at 08:41 +0000, Dave Page wrote:
>
> What do people think about that? Does anyone think it would be an
> unreasonable policy?

I don't think so. You should build 8.0 binaries until the community
stops maintaining PostgreSQL 8.0.

This is what we do for RPMs -- I know it is really a lot of work to
maintain older releases but as a community packager, it is not my "job"
to force people to upgrade to new version by not supplying older
binaries.

Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Devrim GUNDUZ wrote:
-- Start of PGP signed section.
> Hi,
>
> On Sat, 2007-01-27 at 08:41 +0000, Dave Page wrote:
> >
> > What do people think about that? Does anyone think it would be an
> > unreasonable policy?
>
> I don't think so. You should build 8.0 binaries until the community
> stops maintaining PostgreSQL 8.0.
>
> This is what we do for RPMs -- I know it is really a lot of work to
> maintain older releases but as a community packager, it is not my "job"
> to force people to upgrade to new version by not supplying older
> binaries.

Agreed, and I do believe we should be supporting releases as far back as
reasonably possible.

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

+ If your life is a hard drive, Christ can be your backup. +

Dave Page wrote:
> Bill Moran wrote:
>> Does the PostgreSQL project have any similar policy about EoLs? Even just
>> a simple statement like, "it is our goal to support major branches for 2
>> years after release" or some such?
>
> I've been considering only maintaining the current and previous 2
> versions in pgInstaller (the Windows binary distro). But that's a *lot*
> harder to maintain than just PostgreSQL because of all the bundled
> stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.
>
> What do people think about that? Does anyone think it would be an
> unreasonable policy?

Just to have an opinion that differs from what others have said, I think
it's perfectly reasonable given the amount of software that gets packed
in there.

Perhaps we should continue to support the old 8.0 version with just the
binaries-no-installer.zip? IIRC, that one contains just the core
software and not all the addons, which should then make it significantly
easier to maintain?

//Magnus

Dave Page <dpage(at)postgresql(dot)org> writes:
> I've been considering only maintaining the current and previous 2
> versions in pgInstaller (the Windows binary distro). But that's a *lot*
> harder to maintain than just PostgreSQL because of all the bundled
> stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.
> What do people think about that? Does anyone think it would be an
> unreasonable policy?

Actually, I was just wondering last night about whether we should bother
maintaining the 8.0/8.1 Windows ports at all. Everybody knew going in
(or should have known) that 8.0 on Windows would be a pretty raw port
with a lot of issues, as indeed it was, and so long-term support for it
seems a bit pointless. Perhaps the 8.1 port was up to the point where
it would be sane to use for production, or maybe not.

I haven't tracked Windows-specific issues particularly, but I think
there were at least some important patches we didn't back-port because
of complexity. Certainly 8.0 and 8.1 src/backend/port/win32/ files look
quite a bit different. Does anyone recall any specifics about Windows
patches that were back-ported or not?

Anyway I think that a fair case could be made for dropping the 8.0
branch now, and maybe 8.1 too, as far as Windows support goes. What
you want to do going forward is a different decision --- these are
edge cases because of the newness of the port.

regards, tom lane

> Anyway I think that a fair case could be made for dropping the 8.0
> branch now, and maybe 8.1 too, as far as Windows support goes. What
> you want to do going forward is a different decision --- these are
> edge cases because of the newness of the port.

Well as someone who has literally thousands of windows installations
(thank goodness we are not front line support for that). It would be
very helpful if the community did make a confirmed and public statement
about the lifespan of the Windows ports.

It would enable me to get certain customers to upgrade and stop wasting
energy on hunting bugs on unsupported or unlikely to be supported releases.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>> I've been considering only maintaining the current and previous 2
>> versions in pgInstaller (the Windows binary distro). But that's a *lot*
>> harder to maintain than just PostgreSQL because of all the bundled
>> stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.
>> What do people think about that? Does anyone think it would be an
>> unreasonable policy?
>
> Actually, I was just wondering last night about whether we should bother
> maintaining the 8.0/8.1 Windows ports at all. Everybody knew going in
> (or should have known) that 8.0 on Windows would be a pretty raw port
> with a lot of issues, as indeed it was, and so long-term support for it
> seems a bit pointless. Perhaps the 8.1 port was up to the point where
> it would be sane to use for production, or maybe not.
>
> I haven't tracked Windows-specific issues particularly, but I think
> there were at least some important patches we didn't back-port because
> of complexity. Certainly 8.0 and 8.1 src/backend/port/win32/ files look
> quite a bit different. Does anyone recall any specifics about Windows
> patches that were back-ported or not?
>
> Anyway I think that a fair case could be made for dropping the 8.0
> branch now, and maybe 8.1 too, as far as Windows support goes. What
> you want to do going forward is a different decision --- these are
> edge cases because of the newness of the port.

Based on that it would be reasonable to cut 8.0 short, I agree on that.
However, I really don't think we can do that to 8.1. For one, 8.2 is
*way* too new yet. I also do believe we got most of the really big ones
between those (though I can't remember them specifically right now, it's
a feeling I have). But the important part is that either way I think
it's way too early to drop 8.1.

//Magnus

>
> a feeling I have). But the important part is that either way I think
> it's way too early to drop 8.1.
>

I agree. Started a project last summer, using 8.1, rollout is now. > 1 year
for database projects is not unusual, and having the database release
dropped during this time is not nice.

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
fx 01212-5-13695179
-
Python: the only language with more web frameworks than keywords.

Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> Devrim GUNDUZ wrote:
> -- Start of PGP signed section.
> > Hi,
> >
> > On Sat, 2007-01-27 at 08:41 +0000, Dave Page wrote:
> > >
> > > What do people think about that? Does anyone think it would be an
> > > unreasonable policy?
> >
> > I don't think so. You should build 8.0 binaries until the community
> > stops maintaining PostgreSQL 8.0.
> >
> > This is what we do for RPMs -- I know it is really a lot of work to
> > maintain older releases but as a community packager, it is not my "job"
> > to force people to upgrade to new version by not supplying older
> > binaries.
>
> Agreed, and I do believe we should be supporting releases as far back as
> reasonably possible.

The problem I see is that different people have differing opinions on what
is "reasonable".

It might be educational for those not familiar to search back through the
archives for the complaints that cropped up in Nov and Dec regarding the
upcoming EoL of FreeBSD 4.x.

Not sure if the official announcement (that was made several years ago)
made that situation better or worse, but it goes to show that some people
expect stuff to be supported forever. My concern is that without an
official policy, the key developers of the Postgres team will get bogged
down trying to maintain stuff long after it's technically practical, because
some users find it "reasonable."

Of course, the end of "official" support for a project doesn't prevent folks
with an interest from continuing to support it unofficially. The CVS
tree will still be there, etc.

Anyway, just my thoughts on the matter. It's interesting to see the other
discussion that's going on.

-Bill

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/07 11:50, Bill Moran wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Devrim GUNDUZ wrote:
[snip]
> Of course, the end of "official" support for a project doesn't prevent folks
> with an interest from continuing to support it unofficially. The CVS
> tree will still be there, etc.
>
> Anyway, just my thoughts on the matter. It's interesting to see the other
> discussion that's going on.

The Debian Security Team will be patching security issues on v7.4
for another 18 months, if that helps anyone.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFu58lS9HxQb37XmcRAmYkAKCC+SMLzaph6Pby2/M1BGqCbounkgCcDYgd
jkrBZF9CZdZO9q0G92mTqss=
=vs5m
-----END PGP SIGNATURE-----

Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>
>> I've been considering only maintaining the current and previous 2
>> versions in pgInstaller (the Windows binary distro). But that's a *lot*
>> harder to maintain than just PostgreSQL because of all the bundled
>> stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.
>> What do people think about that? Does anyone think it would be an
>> unreasonable policy?
>>
>
> Actually, I was just wondering last night about whether we should bother
> maintaining the 8.0/8.1 Windows ports at all. Everybody knew going in
> (or should have known) that 8.0 on Windows would be a pretty raw port
> with a lot of issues, as indeed it was, and so long-term support for it
> seems a bit pointless. Perhaps the 8.1 port was up to the point where
> it would be sane to use for production, or maybe not.
>
> I haven't tracked Windows-specific issues particularly, but I think
> there were at least some important patches we didn't back-port because
> of complexity. Certainly 8.0 and 8.1 src/backend/port/win32/ files look
> quite a bit different. Does anyone recall any specifics about Windows
> patches that were back-ported or not?
>
> Anyway I think that a fair case could be made for dropping the 8.0
> branch now, and maybe 8.1 too, as far as Windows support goes. What
> you want to do going forward is a different decision --- these are
> edge cases because of the newness of the port.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
My 8.2c,
Having 8.1 end of life this soon after the release of 8.2 seems pretty
harsh. I am a Windows user with systems in the field in production and
it would probably be disconcerting to customers to see/read that the
version they are using will not have the benefits of full community
support going forward.
It should also be considered that it is probably more difficult to
alleviate the concerns of people about using even the *best* Open
Source database on a Windows platform (please don't bash us for using
windows for now it is a necessary evil) It seems reasonable to expect
8.1 to be alive for more than 2 months after its replacement is released.
For most production environments just the QA process for a major version
change could take longer than 2 months to schedule and implement, let
alone roll out to the hopefully growing numbers of customers.

Oisin

> It should also be considered that it is probably more difficult to
> alleviate the concerns of people about using even the *best* Open
> Source database on a Windows platform (please don't bash us for using
> windows for now it is a necessary evil)

As much as I would like to say the community won't bash you for using
windows, we all know better ;). However it is important to note that
this thread is about supporting windows in general.

8.2 is a substantial improvement over the other releases for Win32.

> It seems reasonable to expect
> 8.1 to be alive for more than 2 months after its replacement is released.
> For most production environments just the QA process for a major version
> change could take longer than 2 months to schedule and implement, let
> alone roll out to the hopefully growing numbers of customers.
>

I would agree. However, I don't think it would be unreasonable to
consider when by the time 8.3.1 comes out which if all goes well would
be in the fall (or so).

Then continue our standard long term support for the 8.2+ series of
PostgreSQL which would mean we would like give approximately 5 years
support to that branch.

Sincerely,

Joshua D. Drake

> Oisin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Oisin Glynn <me(at)oisinglynn(dot)com> writes:
> Tom Lane wrote:
>> Anyway I think that a fair case could be made for dropping the 8.0
>> branch now, and maybe 8.1 too, as far as Windows support goes.

> My 8.2c,
> Having 8.1 end of life this soon after the release of 8.2 seems pretty
> harsh.

That's fine, I just wanted to run that idea up the flagpole and see if
anyone would salute. The important point is that no one has spoken
against retiring 8.0-on-Windows now. (Don't tell me people actually
listened to us when we said not to run production with it ;-))

What'd probably be a good idea is for someone to go through the CVS logs
and check for 8.2 Windows portability fixes that have not gotten into
the 8.1 branch. If we want to continue supporting 8.1 then we should
make sure it's up to speed. I think there might have been some changes
we didn't back-port because we hadn't enough confidence in them, but 8.2
has been out long enough now that we can be pretty sure it's not a
regression.

regards, tom lane

Tom Lane wrote:
> Oisin Glynn <me(at)oisinglynn(dot)com> writes:
>> Tom Lane wrote:
>>> Anyway I think that a fair case could be made for dropping the 8.0
>>> branch now, and maybe 8.1 too, as far as Windows support goes.
>
>> My 8.2c,
>> Having 8.1 end of life this soon after the release of 8.2 seems pretty
>> harsh.
>
> That's fine, I just wanted to run that idea up the flagpole and see if
> anyone would salute. The important point is that no one has spoken
> against retiring 8.0-on-Windows now. (Don't tell me people actually
> listened to us when we said not to run production with it ;-))

They didn't, but those of us they call quickly made them upgrade ;)

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Oisin Glynn wrote:
> My 8.2c,
> Having 8.1 end of life this soon after the release of 8.2 seems pretty
> harsh.

Yeah, I agree. In part I'm basing the idea to support the current and 2
previous branches on the amount of work required to build a complete set
of point releases in one go - 3 seems manageable over a weekend. 4 would
probably be possible, but would be more rushed than I'd like.

Also, three just seems like a sensible number to maintain. I kinda like
Magnus' idea to put older releases into a sort of 'retired' mode though,
and build only the binaries for PostgreSQL itself.

Regards, Dave.

Dave Page wrote:
> Oisin Glynn wrote:
>> My 8.2c,
>> Having 8.1 end of life this soon after the release of 8.2 seems pretty
>> harsh.
>
> Yeah, I agree. In part I'm basing the idea to support the current and 2
> previous branches on the amount of work required to build a complete set
> of point releases in one go - 3 seems manageable over a weekend. 4 would
> probably be possible, but would be more rushed than I'd like.

I don't see a problem if the updates for the current and previous
release binaries are available on the current schedule and older release
update binaries are available a few days to a week later.

The other option is to extend the time allocated between the decision to
OK the releases and making the binaries available.

For example we could say source release available friday with 8.2.x and
8.1.x binaries available monday then 8.0.x and 7.4.x binaries available
thursday or friday.

A lot of users may download the releases as they come out but most with
production servers won't be installing them the same day.

--

Shane Ambler
pgSQL(at)007Marketing(dot)com

Get Sheeky @ http://Sheeky.Biz

Dave Page wrote:
> Also, three just seems like a sensible number to maintain. I kinda
> like Magnus' idea to put older releases into a sort of 'retired' mode
> though, and build only the binaries for PostgreSQL itself.

But would that give people who have previously used the full installer
an upgrade path (that doesn't break everything around it)?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Bill Moran wrote:
> Does the PostgreSQL project have any similar policy about EoLs?

Is it a question for community support, or for various
commercial vendor's support policies?

How long companies selling "postgresql support" support each
release could be one of the more important characteristics
that differentiates one vendor from another.

I think it would be useful on postgresql.org's professional
support pages to list such policies like "company X supports
version 7.2 through 2007; 8.0 through 2009" etc. Do any
of the support organizations besides Red Hat specify how
long they'll support particular versions?

If you're asking about community support I'd hope the
answer is "so long as supporting them is a good use of
the community's time when compared to other work". Since
understanding failure modes over long periods of time is
probably of great interest for database developers one
could guess that this means old versions will be supported
as long as they're pretty similar to the newest version.

In response to Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>:
> Bill Moran wrote:
> > Does the PostgreSQL project have any similar policy about EoLs?
>
> Is it a question for community support, or for various
> commercial vendor's support policies?

I'm not worried about vendors. If we're relying on vendor support, I'll
get a signed contract from them.

[snip]

> If you're asking about community support I'd hope the
> answer is "so long as supporting them is a good use of
> the community's time when compared to other work". Since
> understanding failure modes over long periods of time is
> probably of great interest for database developers one
> could guess that this means old versions will be supported
> as long as they're pretty similar to the newest version.

Sure. But some of us (you know, me, for example) live in a hybrid world --
somewhere between open source and business. I can't say thinks like, "the
next version will be released when it's ready"

I have enough open source background to understand the whole "it will
be supported as long as people care to work on it" mentality. But
guidelines would be nice. As I pointed out, the FreeBSD project seems
to have a done a really great job laying out guidelines as to how and
when they'll support things (at least from my viewpoint). I guess
what I'm really doing is trying to convince the Postgres folks that
they should adopt that model. :D

--
Bill Moran
Collaborative Fusion Inc.

On Jan 27, 2007, at 3:41 AM, Dave Page wrote:
>> Does the PostgreSQL project have any similar policy about EoLs?
>> Even just
>> a simple statement like, "it is our goal to support major branches
>> for 2
>> years after release" or some such?
>
> I've been considering only maintaining the current and previous 2
> versions in pgInstaller (the Windows binary distro). But that's a
> *lot*
> harder to maintain than just PostgreSQL because of all the bundled
> stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.
>
> What do people think about that? Does anyone think it would be an
> unreasonable policy?

FWIW, I looked in the archives at the last time we discussed this a
while ago; the popular proposal seemed to be that at a *minimum* we'd
support a version for 2 years *after* it was replaced. IE: 8.0
support could end 2 years after 8.1 came out (which would be
somewhere around this Dec., IIRC).

But it's also important to point out that a number of community
members are on the hook to support old versions due to their day
jobs; with Tom/Red Hat/7.3 (or is it 7.4?) probably being the best
example. IIRC Sun's support policy is 5 years, so presumably someone
will have to maintain whatever version they initially shipped with
(8.1?) for quite some time as well.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to Jim Nasby <decibel(at)decibel(dot)org>:
> On Jan 27, 2007, at 3:41 AM, Dave Page wrote:
> >> Does the PostgreSQL project have any similar policy about EoLs?
> >> Even just
> >> a simple statement like, "it is our goal to support major branches
> >> for 2
> >> years after release" or some such?
> >
> > I've been considering only maintaining the current and previous 2
> > versions in pgInstaller (the Windows binary distro). But that's a
> > *lot*
> > harder to maintain than just PostgreSQL because of all the bundled
> > stuff. In other words, when 8.3 is out, the 8.0 series gets dropped.
> >
> > What do people think about that? Does anyone think it would be an
> > unreasonable policy?
>
> FWIW, I looked in the archives at the last time we discussed this a
> while ago; the popular proposal seemed to be that at a *minimum* we'd
> support a version for 2 years *after* it was replaced. IE: 8.0
> support could end 2 years after 8.1 came out (which would be
> somewhere around this Dec., IIRC).
>
> But it's also important to point out that a number of community
> members are on the hook to support old versions due to their day
> jobs; with Tom/Red Hat/7.3 (or is it 7.4?) probably being the best
> example. IIRC Sun's support policy is 5 years, so presumably someone
> will have to maintain whatever version they initially shipped with
> (8.1?) for quite some time as well.

Right. and my original point in starting this thread is that it would
be valuable to the community if all this information were gathered up
and documented somewhere.

--
Bill Moran
Collaborative Fusion Inc.

>> But it's also important to point out that a number of community
>> members are on the hook to support old versions due to their day
>> jobs; with Tom/Red Hat/7.3 (or is it 7.4?) probably being the best
>> example. IIRC Sun's support policy is 5 years, so presumably someone
>> will have to maintain whatever version they initially shipped with
>> (8.1?) for quite some time as well.
>
> Right. and my original point in starting this thread is that it would
> be valuable to the community if all this information were gathered up
> and documented somewhere.

Go for it! :)

Sincerely,

Joshua D. Drake

>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

In response to "Joshua D. Drake" <jd(at)commandprompt(dot)com>:
>
> >> But it's also important to point out that a number of community
> >> members are on the hook to support old versions due to their day
> >> jobs; with Tom/Red Hat/7.3 (or is it 7.4?) probably being the best
> >> example. IIRC Sun's support policy is 5 years, so presumably someone
> >> will have to maintain whatever version they initially shipped with
> >> (8.1?) for quite some time as well.
> >
> > Right. and my original point in starting this thread is that it would
> > be valuable to the community if all this information were gathered up
> > and documented somewhere.
>
> Go for it! :)

I suppose I should have seen that coming ... :)

--
Bill Moran
Collaborative Fusion Inc.

>>> Right. and my original point in starting this thread is that it would
>>> be valuable to the community if all this information were gathered up
>>> and documented somewhere.
>> Go for it! :)
>
> I suppose I should have seen that coming ... :)

Yes I believe that would have been pretty obvious :)

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Dave Page wrote:
>
> Also, three just seems like a sensible number to maintain. I kinda like
> Magnus' idea to put older releases into a sort of 'retired' mode though,
> and build only the binaries for PostgreSQL itself.

The other option would be for one or more Windows users to step forward
and say "I'll package 8.0 if I get some help".

--
Richard Huxton
Archonet Ltd

Richard Huxton wrote:
> Dave Page wrote:
>>
>> Also, three just seems like a sensible number to maintain. I kinda
>> like Magnus' idea to put older releases into a sort of 'retired' mode
>> though, and build only the binaries for PostgreSQL itself.
>
> The other option would be for one or more Windows users to step forward
> and say "I'll package 8.0 if I get some help".
>
Or in case one of the PostgreSQL support companies actually have
customers running this that needs it, they could do it. Obviously edb
doesn't feel the need, since Dave's not been ordered to :-)

//Magnus

Magnus Hagander wrote:
> Richard Huxton wrote:
>> Dave Page wrote:
>>> Also, three just seems like a sensible number to maintain. I kinda
>>> like Magnus' idea to put older releases into a sort of 'retired' mode
>>> though, and build only the binaries for PostgreSQL itself.
>> The other option would be for one or more Windows users to step forward
>> and say "I'll package 8.0 if I get some help".
>>
> Or in case one of the PostgreSQL support companies actually have
> customers running this that needs it, they could do it. Obviously edb
> doesn't feel the need, since Dave's not been ordered to :-)

Nor does CMD.

Sincerely,

Joshua D. Drake

>
> //Magnus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Magnus Hagander wrote:
> Richard Huxton wrote:
>> Dave Page wrote:
>>> Also, three just seems like a sensible number to maintain. I kinda
>>> like Magnus' idea to put older releases into a sort of 'retired' mode
>>> though, and build only the binaries for PostgreSQL itself.
>> The other option would be for one or more Windows users to step forward
>> and say "I'll package 8.0 if I get some help".
>>
> Or in case one of the PostgreSQL support companies actually have
> customers running this that needs it, they could do it.

I doubt we have any customers running it.

> Obviously edb
> doesn't feel the need, since Dave's not been ordered to :-)

I'm left to my own devices as far as community work is concerned. Which
is nice :-)

Regards, Dave

>> Obviously edb
>> doesn't feel the need, since Dave's not been ordered to :-)
>
> I'm left to my own devices as far as community work is concerned. Which
> is nice :-)

Well, if edb had customers *using* it, I'm sure they would tell you to
do it even if you didn't want to :-)

//Magnus

Magnus Hagander wrote:
>>> Obviously edb
>>> doesn't feel the need, since Dave's not been ordered to :-)
>> I'm left to my own devices as far as community work is concerned. Which
>> is nice :-)
>
> Well, if edb had customers *using* it, I'm sure they would tell you to
> do it even if you didn't want to :-)

Quite probably.

/D