Predicted lifespan of different PostgreSQL branches

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@007Marketing.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.l.johnson@cox.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@momjian.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@momjian.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@svana.org> http://svana.org/kleptog/

Shane Ambler <pgsql@007Marketing.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@momjian.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@postgresql.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@postgresql.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@postgresql.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.