Thread: Lifecycle of PostgreSQL releases

Erik Jones wrote:
> On Mar 14, 2007, at 6:17 PM, CAJ CAJ wrote:
>
>> Hello,
>>
>> What is the lifecycle of a 8.0/8.1/8.2 releases? With 8.3 scheduled to
>> be released in July, what will be the status of the 7.4.x branch?
>>
>> We are planning pg upgrades from 8.0.x/7.4.x to 6.2.x and were
>> wondering if it's worth waiting for the 8.3 release.
>
> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
> waiting.  Upgrade at the soonest available opportunity, expecially the
> 7.4.x servers.

I don't really agree with this. If he is running 7.4.16 there very well
may be zero compelling reason for him to upgrade.

8.3 is shaping up to be a really nice release, it could very much be
worth it to wait 3-4 months and call 8.3 their static release for the
next 5 years.

Joshua D. Drake


>
> erik jones <erik@myemma.com>
> sofware developer
> 615-296-0838
> emma(r)
>
>
>
>


--

      === 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/

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Erik Jones wrote:
>> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
>> waiting.  Upgrade at the soonest available opportunity, expecially the
>> 7.4.x servers.

> I don't really agree with this. If he is running 7.4.16 there very well
> may be zero compelling reason for him to upgrade.

Really?  There are any number of anecdotal reports of massive speed
improvements between 7.x and various 8.x versions.  Not to mention a
few feature improvements.

Now it could well be that none of those affect the OP but 8.3 will have
the particular shade of magic pixie dust his queries need.  But it seems
at least as likely that 8.3 will be no significant improvement over 8.2
for him.  Without any real details about his app, you can't call it
either way.

I tend to agree with Erik that if you have a window now to upgrade off
of 7.x, you should do it, rather than waiting for the next release.

            regards, tom lane

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> Erik Jones wrote:
>>> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
>>> waiting.  Upgrade at the soonest available opportunity, expecially the
>>> 7.4.x servers.
>
>> I don't really agree with this. If he is running 7.4.16 there very well
>> may be zero compelling reason for him to upgrade.
>
> Really?  There are any number of anecdotal reports of massive speed
> improvements between 7.x and various 8.x versions.  Not to mention a
> few feature improvements.

There is zero question that 8.2 is faster than 7.4 *but* if 7.4 isn't
slow for them... Note, that I meant no reason for him to upgrade 7.4
*right now*. He could wait for 8.3. (I think he should get off 7.4 in
general)

>
> Now it could well be that none of those affect the OP but 8.3 will have
> the particular shade of magic pixie dust his queries need.  But it seems
> at least as likely that 8.3 will be no significant improvement over 8.2
> for him.  Without any real details about his app, you can't call it
> either way.

I can't really argue for 8.2 versus 8.3, but I can argue that as 8.3 is
literally around the corner, it may make sense to wait.

Mileage may vary of course.

Joshua D. Drake

>
> I tend to agree with Erik that if you have a window now to upgrade off
> of 7.x, you should do it, rather than waiting for the next release.
>
>             regards, tom lane
>


--

      === 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/

"Joshua D. Drake" <jd@commandprompt.com> writes:
> I can't really argue for 8.2 versus 8.3, but I can argue that as 8.3 is
> literally around the corner, it may make sense to wait.

Today is the ides of March ... while the most optimistic estimate I've
heard for 8.3 release is high summer.  Maybe that's just around the
corner by some time scales, but I strongly counsel the OP not to try to
hold his breath till then.

            regards, tom lane

Joshua D. Drake escribió:
> Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> >> Erik Jones wrote:
> >>> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
> >>> waiting.  Upgrade at the soonest available opportunity, expecially the
> >>> 7.4.x servers.
> >
> >> I don't really agree with this. If he is running 7.4.16 there very well
> >> may be zero compelling reason for him to upgrade.
> >
> > Really?  There are any number of anecdotal reports of massive speed
> > improvements between 7.x and various 8.x versions.  Not to mention a
> > few feature improvements.
>
> There is zero question that 8.2 is faster than 7.4 *but* if 7.4 isn't
> slow for them... Note, that I meant no reason for him to upgrade 7.4
> *right now*. He could wait for 8.3. (I think he should get off 7.4 in
> general)

He could wait for 8.4 as well, as it will be probably faster and have
more features than 8.3.  Following your reasoning, one could wait
essentially forever.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Thu, 2007-03-15 at 00:10, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > Erik Jones wrote:
> >> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
> >> waiting.  Upgrade at the soonest available opportunity, expecially the
> >> 7.4.x servers.
>
> > I don't really agree with this. If he is running 7.4.16 there very well
> > may be zero compelling reason for him to upgrade.
>
> Really?  There are any number of anecdotal reports of massive speed
> improvements between 7.x and various 8.x versions.  Not to mention a
> few feature improvements.
>
> Now it could well be that none of those affect the OP but 8.3 will have
> the particular shade of magic pixie dust his queries need.  But it seems
> at least as likely that 8.3 will be no significant improvement over 8.2
> for him.  Without any real details about his app, you can't call it
> either way.
>
> I tend to agree with Erik that if you have a window now to upgrade off
> of 7.x, you should do it, rather than waiting for the next release.

I love pgsql as much as anybody, and I generally don't run the latest
release in production until it's about 6 months out of the gate.
Between testing and approval and upgrading all the systems that aren't
production, by the time a new version sees production it pretty much has
to be 4 to 6 months old.

I also tend to run every other version.  I've run 7.2, then 7.4, then
8.1.  I've tested and played with 8.2 and speed wise, it wasn't a
compelling enough upgrade to start the very long process of replacing
8.1 with.  By the time 8.3 comes out, I'll be about ready to start
evaluating our next version of pgsql.

I have to say the update to 8.1 was very compelling, as the query
optimizer was much better, and the ability to use indexes on date
columns with references like now() - interval '5 days' was a huge thing
for my reporting apps.

>> There is zero question that 8.2 is faster than 7.4 *but* if 7.4 isn't
>> slow for them... Note, that I meant no reason for him to upgrade 7.4
>> *right now*. He could wait for 8.3. (I think he should get off 7.4 in
>> general)
>
> He could wait for 8.4 as well, as it will be probably faster and have
> more features than 8.3.  Following your reasoning, one could wait
> essentially forever.

You have got to be kidding. There is quite a bit of difference between 3
months and 17 months. From the persons email, he obviously has an array
of production machines. This isn't hack fest 2000, just load up whatever.

My professional opinion, and frankly the opinion we are telling our
customers (except those that will explicitly benefit from something in
8.2) is to wait for 8.3.

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/

> I also tend to run every other version.  I've run 7.2, then 7.4, then
> 8.1.  I've tested and played with 8.2 and speed wise, it wasn't a
> compelling enough upgrade to start the very long process of replacing
> 8.1 with.  By the time 8.3 comes out, I'll be about ready to start
> evaluating our next version of pgsql.
>
> I have to say the update to 8.1 was very compelling, as the query
> optimizer was much better, and the ability to use indexes on date
> columns with references like now() - interval '5 days' was a huge thing
> for my reporting apps.

Yeah 8.1 was a great milestone, being able to allocate more
shared_buffers has been a great boon for many of our customers that are
running 4+ GIG of ram.

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/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> I can't really argue for 8.2 versus 8.3, but I can argue that as 8.3 is
>> literally around the corner, it may make sense to wait.
>
> Today is the ides of March ... while the most optimistic estimate I've
> heard for 8.3 release is high summer.  Maybe that's just around the
> corner by some time scales, but I strongly counsel the OP not to try to
> hold his breath till then.

Well I guess that comes back to user requirements. Some general non
tested statistics:

1. More people will run 8.3 than 8.2. Why? Because 8.3 will be in the
wild as current stable longer than 8.2.

2. Red Hat ES will likely never ship 8.2, ES 5 shipped with 8.1. That
means more yet even more people will run 8.1 versus 8.2 (which doesn't
argue for 8.3 but does argue against 8.2)

3. Ubuntu Dapper, which is LTS (like ES) ships with 8.1, the next LTS
will ship with 8.3 (likely).

4. Novell SUSE, shipps 8.1.5 in 10.2, 10.3 is going to ship with 8.3
(unless 8.3 slips horribly)

4. Solaris (JoshB help me here), ships with 8.1.


The trend here is that although 8.2 is a good release, people won't see
the benefits of 8.2 until they install 8.3 or 8.4. Further, because
people are going to wait (we are talking generally here).

It just doesn't make sense, to go through an entire upgrade cycle over
multiple machines just to upgrade to what will likely be obsolete
(because 8.3 will be out) by the time he works out all the kinks of the
upgrade in the first place.

Not everyone will agree, and that's cool. If he wants to upgrade, have
at it.

Sincerely,

Joshua D. Drake





>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>


--

      === 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/

"Joshua D. Drake" <jd@commandprompt.com> writes:
> 1. More people will run 8.3 than 8.2. Why? Because 8.3 will be in the
> wild as current stable longer than 8.2.

Oh, gimme a break, Josh.  A year or more from now that argument would be
relevant, but unless you are going to counsel your customers not to
update till mid-2008, it's completely irrelevant to whether it makes
sense to update now.  If you *are* going to tell them to wait until
8.3.4 or so (which I can see an argument for, if you don't like being
an early adopter), won't you then be in exactly the same position that
"8.4 is just around the corner"?

Your other four points are mere rehashings of that one.

            regards, tom lane

If they have a support contract for, say, RHEL, why migrate to something
that support contract doesn't cover?  Those had better be some very
important features or some very critical bug fixes, the latter of which
are very likely to get backported if they're versions covered by a
support contract.

The upgrade question is "why?" not "why not?".

--
Brandon Aiken
CS/IT Systems Engineer

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Thursday, March 15, 2007 2:00 PM
To: Joshua D. Drake
Cc: Erik Jones; CAJ CAJ; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Lifecycle of PostgreSQL releases

"Joshua D. Drake" <jd@commandprompt.com> writes:
> 1. More people will run 8.3 than 8.2. Why? Because 8.3 will be in the
> wild as current stable longer than 8.2.

Oh, gimme a break, Josh.  A year or more from now that argument would be
relevant, but unless you are going to counsel your customers not to
update till mid-2008, it's completely irrelevant to whether it makes
sense to update now.  If you *are* going to tell them to wait until
8.3.4 or so (which I can see an argument for, if you don't like being
an early adopter), won't you then be in exactly the same position that
"8.4 is just around the corner"?

Your other four points are mere rehashings of that one.

            regards, tom lane

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

** LEGAL DISCLAIMER **
Statements made in this e-mail may or may not reflect the views and
opinions of Wineman Technology, Inc. or its employees.

This e-mail message and any attachments may contain legally privileged,
confidential or proprietary information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this e-mail
message is strictly prohibited. If you have received this message in
error, please immediately notify the sender and delete this e-mail
message from your computer.

>
> Your other four points are mere rehashings of that one.

Yes. All of my points directly revolve around the reality that 8.2 is a
short cycle release and that 8.3 is a long cycle release. Further that
due to 8.2 being a short cycle release, it will not see as much
production action as 8.3 (and definitely not 8.1 per the current
enterprise releases).

That to me is an extremely valid point, and a point that my customers
have made *to me*.

Example discussion with customer:

Customer: CMD, should we update to 8.2.3
CMD: Is there something in 8.2.3 that will benefit you?
Customer: We don't know
CMD: Are you having problems with 8.1? (We try to push all customers to
at least 8.1)
Customer: No, it is just that 8.2 is the current release
CMD: True, but 8.3 is due out in the summer and 8.3 is a standard cycle
release
Customer: Oh... o.k. let's wait.
CMD: I think that is probably prudent.


I am not just coming up with this stuff to be difficult. This is real
world here. Couple the above, with my previous post and *unless* there
is something that 8.2 gives you explicitly (and there are reasons to
upgrade to 8.2), there *may* (note word *may*) not be a reason to upgrade.

Take that and add, that 8.3 is just around the corner and my argument
stands.

The only argument anyone that I see against the above is the, "upgrade
because it is shiny argument". Which indeed may (there is that word
again) be enough. In business, shiny can be bad.

What I see in this thread, is people saying 8.2.3 is the cat's meow,
which of course is true. That doesn't mean that you need to upgrade.

I have a 8 year old Saab 9-5 V6 Turbo. It has leather, heated and air
conditioned seats. True, it is 8 years old, but it only has 62k on it.
The new model, offers some better styling, a 4 cylinder with more
horsepower and the paint reflects light just a little better.

Does that mean I want to take my debt free car, and trade it in for a
new 40k loan? Not on your life, my 8 year old Saab has at least 2 more
years in it and I was smart and bought an extended warranty.

Why is it, that every time someone suggests that someone may not need to
upgrade to the latest and greatest paint job, social networking site or
piece of software that people get upset?

Sincerely,

Joshua D. Drake


>
>             regards, tom lane
>


--

      === 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 an attempt to throw the authorities off his trail, erik@myemma.com (Erik Jones) transmitted:
> On Mar 14, 2007, at 6:17 PM, CAJ CAJ wrote:
>
>
>           Hello,
>
>      What is the lifecycle of a 8.0/8.1/8.2 releases? With 8.3 scheduled to be released in July, what will be the
statusof the 7.4.x 
>      branch?
>
>      We are planning pg upgrades from 8.0.x/7.4.x to 6.2.x and were wondering if it's worth waiting for the 8.3
release.
>
> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
> waiting.  Upgrade at the soonest available opportunity, expecially
> the 7.4.x servers.

I hope so too; if performance isn't a direct issue, and doing upgrades
is seriously inconvenient, it might well be worth waiting for 8.3.

We've got some little databases around here and there which don't
*NEED* upgrading from any perspective other than that we'd loosely
prefer to be on "modern" versions of PostgreSQL.

For a small "web contacts" database, or for a lightly loaded MRTG-like
application, an upgrade may not actually be very valuable.
--
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxdatabases.info/info/lisp.html
"I'm sure that nobody here would dream of  misusing the Arpanet.  It's
as unthinkable as fornication, or smoking pot."  -- RMS

In an attempt to throw the authorities off his trail, jd@commandprompt.com ("Joshua D. Drake") transmitted:
>>> There is zero question that 8.2 is faster than 7.4 *but* if 7.4 isn't
>>> slow for them... Note, that I meant no reason for him to upgrade 7.4
>>> *right now*. He could wait for 8.3. (I think he should get off 7.4 in
>>> general)
>>
>> He could wait for 8.4 as well, as it will be probably faster and have
>> more features than 8.3.  Following your reasoning, one could wait
>> essentially forever.
>
> You have got to be kidding. There is quite a bit of difference between 3
> months and 17 months. From the persons email, he obviously has an array
> of production machines. This isn't hack fest 2000, just load up whatever.
>
> My professional opinion, and frankly the opinion we are telling our
> customers (except those that will explicitly benefit from something in
> 8.2) is to wait for 8.3.

At Afilias, we're mostly thru our upgrades from 7.4 to 8.1; while I'm
running buildfarm on 8.2, there's only one case where I'm presently
considering an 8.2 upgrade (the app *would* specifically benefit), and
I'm expecting that we won't bother much with the 8.2 branch.

We had a particular challenge that some apps got stuck on 7.4 for
excessively long because of JDBC customization; that held back
upgrades.  But now that that is "unstuck," I'm still not pushing to
schedule 8.2 upgrades for everything just because it's now "more
possible;" the upgrade process involves quite a lot of work, enough
that I think I'd rather skip to the next model.

I daresay that 8.1 was everything I was hoping for; the performance
improvements are looking really good.  I was living with 7.4; 8.1 is
plenty better and I think I can probably live with that for a year
before saying "oh, that's not good enough - I want 8.3!!!"

I'm not stuck on that answer; there's one system I *do* want to put on
8.2.  But I'm mostly inclined to wait for 8.3 for most of my "further
upgrade needs."
--
"cbbrowne","@","gmail.com"
http://linuxdatabases.info/info/
Save the whales. Collect the whole set.

On Mar 15, 2007, at 10:22 AM, Alvaro Herrera wrote:

> He could wait for 8.4 as well, as it will be probably faster and have
> more features than 8.3.  Following your reasoning, one could wait
> essentially forever.

Hmmmm... precisely the reason my cell phone hasn't been replaced in a
looooong time :-)

I'm evaluating whether to upgrade from 8.1 to 8.2 still... but the
jump from a 7.4 to 8.2 is to me a no-brainer once you've ironed out
the minor issues with syntax pickyness that 8.x imposes on some
sloppy queries that worked with 7.4

alvherre@commandprompt.com (Alvaro Herrera) writes:
> Joshua D. Drake escribió:
>> Tom Lane wrote:
>> > "Joshua D. Drake" <jd@commandprompt.com> writes:
>> >> Erik Jones wrote:
>> >>> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
>> >>> waiting.  Upgrade at the soonest available opportunity, expecially the
>> >>> 7.4.x servers.
>> >
>> >> I don't really agree with this. If he is running 7.4.16 there very well
>> >> may be zero compelling reason for him to upgrade.
>> >
>> > Really?  There are any number of anecdotal reports of massive speed
>> > improvements between 7.x and various 8.x versions.  Not to mention a
>> > few feature improvements.
>>
>> There is zero question that 8.2 is faster than 7.4 *but* if 7.4 isn't
>> slow for them... Note, that I meant no reason for him to upgrade 7.4
>> *right now*. He could wait for 8.3. (I think he should get off 7.4 in
>> general)
>
> He could wait for 8.4 as well, as it will be probably faster and have
> more features than 8.3.  Following your reasoning, one could wait
> essentially forever.

That *is* true for the case of the "really lightly used" database
where there isn't any particularly compelling reason to look to
upgrade.

- If it's providing results fast enough for the users, then they have
  no reason to be demanding an upgrade.

- If it has enough functionality to support the queries they're
  running, again, there's no good reason to demand an upgrade

The only reason to feel "forced" to upgrade is that at some point, the
old version essentially falls out of support.

I'd feel uncomfortable, today, about having any 7.3 databases around,
from that perspective, and I'd certainly be inclined to "leap" them
up, probably to 8.2.  My discomfort level is such that I'd want to do
that now, before 8.3 appears.  I fully expect that once 8.3 is around,
interest in supporting 7.4 will also begin to dwindle, and that's a
good enough reason to want to get off 7.4, not now, but soon enough.

Now, *eventually* Josh will want to upgrade to a new Saab, because the
old one will start getting expensive to maintain (fundamentally
because more and more bits of it will start aging noticeably).  My
Honda Civic needs a bit of work now; in a couple years, the cost of
maintaining it may grow, and I'll want to get something new.
*Eventually*, I'll want to upgrade to a new cell phone because the old
one will be scratched up and the battery will cease to hold a decent
charge.  But that's not true yet.

We don't need upgrades on these things *instantly* because of the huge
value of the utility of the upgraded features; we're using the
features modestly enough that we can afford to wait a while.

On the other hand, I have some apps where I'm quite looking forward to
8.3 because I expect to want to use 8.3's improvements in speed and
functionality Pretty Early in its release cycle.

Both scenarios can certainly occur.
--
"cbbrowne","@","linuxdatabases.info"
http://www3.sympatico.ca/cbbrowne/multiplexor.html
Rules of the Evil Overlord #206. "When my Legions of Terror park their
vehicle  to do  reconnaissance on  foot,  they will  be instructed  to
employ The Club." <http://www.eviloverlord.com/>

> I also tend to run every other version.  I've run 7.2, then 7.4, then
> 8.1.  I've tested and played with 8.2 and speed wise, it wasn't a
> compelling enough upgrade to start the very long process of replacing
> 8.1 with.  By the time 8.3 comes out, I'll be about ready to start
> evaluating our next version of pgsql.
>
> I have to say the update to 8.1 was very compelling, as the query
> optimizer was much better, and the ability to use indexes on date
> columns with references like now() - interval '5 days' was a huge thing
> for my reporting apps.

Yeah 8.1 was a great milestone, being able to allocate more
shared_buffers has been a great boon for many of our customers that are
running 4+ GIG of ram.

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/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

In an attempt to throw the authorities off his trail, erik@myemma.com (Erik Jones) transmitted:
> On Mar 14, 2007, at 6:17 PM, CAJ CAJ wrote:
>
>
>           Hello,
>
>      What is the lifecycle of a 8.0/8.1/8.2 releases? With 8.3 scheduled to be released in July, what will be the
statusof the 7.4.x 
>      branch?
>
>      We are planning pg upgrades from 8.0.x/7.4.x to 6.2.x and were wondering if it's worth waiting for the 8.3
release.
>
> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
> waiting.  Upgrade at the soonest available opportunity, expecially
> the 7.4.x servers.

I hope so too; if performance isn't a direct issue, and doing upgrades
is seriously inconvenient, it might well be worth waiting for 8.3.

We've got some little databases around here and there which don't
*NEED* upgrading from any perspective other than that we'd loosely
prefer to be on "modern" versions of PostgreSQL.

For a small "web contacts" database, or for a lightly loaded MRTG-like
application, an upgrade may not actually be very valuable.
--
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxdatabases.info/info/lisp.html
"I'm sure that nobody here would dream of  misusing the Arpanet.  It's
as unthinkable as fornication, or smoking pot."  -- RMS

alvherre@commandprompt.com (Alvaro Herrera) writes:
> Joshua D. Drake escribió:
>> Tom Lane wrote:
>> > "Joshua D. Drake" <jd@commandprompt.com> writes:
>> >> Erik Jones wrote:
>> >>> I really hope you meant upgrades to 8.2.x.  And, no, it's not worth
>> >>> waiting.  Upgrade at the soonest available opportunity, expecially the
>> >>> 7.4.x servers.
>> >
>> >> I don't really agree with this. If he is running 7.4.16 there very well
>> >> may be zero compelling reason for him to upgrade.
>> >
>> > Really?  There are any number of anecdotal reports of massive speed
>> > improvements between 7.x and various 8.x versions.  Not to mention a
>> > few feature improvements.
>>
>> There is zero question that 8.2 is faster than 7.4 *but* if 7.4 isn't
>> slow for them... Note, that I meant no reason for him to upgrade 7.4
>> *right now*. He could wait for 8.3. (I think he should get off 7.4 in
>> general)
>
> He could wait for 8.4 as well, as it will be probably faster and have
> more features than 8.3.  Following your reasoning, one could wait
> essentially forever.

That *is* true for the case of the "really lightly used" database
where there isn't any particularly compelling reason to look to
upgrade.

- If it's providing results fast enough for the users, then they have
  no reason to be demanding an upgrade.

- If it has enough functionality to support the queries they're
  running, again, there's no good reason to demand an upgrade

The only reason to feel "forced" to upgrade is that at some point, the
old version essentially falls out of support.

I'd feel uncomfortable, today, about having any 7.3 databases around,
from that perspective, and I'd certainly be inclined to "leap" them
up, probably to 8.2.  My discomfort level is such that I'd want to do
that now, before 8.3 appears.  I fully expect that once 8.3 is around,
interest in supporting 7.4 will also begin to dwindle, and that's a
good enough reason to want to get off 7.4, not now, but soon enough.

Now, *eventually* Josh will want to upgrade to a new Saab, because the
old one will start getting expensive to maintain (fundamentally
because more and more bits of it will start aging noticeably).  My
Honda Civic needs a bit of work now; in a couple years, the cost of
maintaining it may grow, and I'll want to get something new.
*Eventually*, I'll want to upgrade to a new cell phone because the old
one will be scratched up and the battery will cease to hold a decent
charge.  But that's not true yet.

We don't need upgrades on these things *instantly* because of the huge
value of the utility of the upgraded features; we're using the
features modestly enough that we can afford to wait a while.

On the other hand, I have some apps where I'm quite looking forward to
8.3 because I expect to want to use 8.3's improvements in speed and
functionality Pretty Early in its release cycle.

Both scenarios can certainly occur.
--
"cbbrowne","@","linuxdatabases.info"
http://www3.sympatico.ca/cbbrowne/multiplexor.html
Rules of the Evil Overlord #206. "When my Legions of Terror park their
vehicle  to do  reconnaissance on  foot,  they will  be instructed  to
employ The Club." <http://www.eviloverlord.com/>

As the owner of a 1986 Toyota Celica, I can accept the argument that a
newer car with slightly brighter paint might not be worth the switch.

However, considering the number of features proposed for 8.3, we might
not have 8.3 final until September/October.  I am not saying that will
happen, but it is certainly possible.  And we are now publicly stating
our proposed 8.3 release date, so we might be inundated with "Where is
8.3" questions in August --- again just a possibility.


---------------------------------------------------------------------------

Joshua D. Drake wrote:
>
> >
> > Your other four points are mere rehashings of that one.
>
> Yes. All of my points directly revolve around the reality that 8.2 is a
> short cycle release and that 8.3 is a long cycle release. Further that
> due to 8.2 being a short cycle release, it will not see as much
> production action as 8.3 (and definitely not 8.1 per the current
> enterprise releases).
>
> That to me is an extremely valid point, and a point that my customers
> have made *to me*.
>
> Example discussion with customer:
>
> Customer: CMD, should we update to 8.2.3
> CMD: Is there something in 8.2.3 that will benefit you?
> Customer: We don't know
> CMD: Are you having problems with 8.1? (We try to push all customers to
> at least 8.1)
> Customer: No, it is just that 8.2 is the current release
> CMD: True, but 8.3 is due out in the summer and 8.3 is a standard cycle
> release
> Customer: Oh... o.k. let's wait.
> CMD: I think that is probably prudent.
>
>
> I am not just coming up with this stuff to be difficult. This is real
> world here. Couple the above, with my previous post and *unless* there
> is something that 8.2 gives you explicitly (and there are reasons to
> upgrade to 8.2), there *may* (note word *may*) not be a reason to upgrade.
>
> Take that and add, that 8.3 is just around the corner and my argument
> stands.
>
> The only argument anyone that I see against the above is the, "upgrade
> because it is shiny argument". Which indeed may (there is that word
> again) be enough. In business, shiny can be bad.
>
> What I see in this thread, is people saying 8.2.3 is the cat's meow,
> which of course is true. That doesn't mean that you need to upgrade.
>
> I have a 8 year old Saab 9-5 V6 Turbo. It has leather, heated and air
> conditioned seats. True, it is 8 years old, but it only has 62k on it.
> The new model, offers some better styling, a 4 cylinder with more
> horsepower and the paint reflects light just a little better.
>
> Does that mean I want to take my debt free car, and trade it in for a
> new 40k loan? Not on your life, my 8 year old Saab has at least 2 more
> years in it and I was smart and bought an extended warranty.
>
> Why is it, that every time someone suggests that someone may not need to
> upgrade to the latest and greatest paint job, social networking site or
> piece of software that people get upset?
>
> Sincerely,
>
> Joshua D. Drake
>
>
> >
> >             regards, tom lane
> >
>
>
> --
>
>       === 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/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

Bruce Momjian wrote:
> As the owner of a 1986 Toyota Celica, I can accept the argument that a
> newer car with slightly brighter paint might not be worth the switch.
>
> However, considering the number of features proposed for 8.3, we might
> not have 8.3 final until September/October.

That may change the playing field and as of yet that is not even a
consideration. The current plan (which is what we must base our
decisions on) is that we will release in June/July.

>  I am not saying that will
> happen, but it is certainly possible.  And we are now publicly stating
> our proposed 8.3 release date, so we might be inundated with "Where is
> 8.3" questions in August --- again just a possibility.

Sure but going on speculation isn't worth it. The community has stated,
hey this is a our goal. We plan around that goal. If the goal changes,
then we reassess.

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/

Joshua D. Drake wrote:
> Example discussion with customer:
>
> Customer: CMD, should we update to 8.2.3
> CMD: Is there something in 8.2.3 that will benefit you?
> Customer: We don't know
> CMD: Are you having problems with 8.1? (We try to push all customers to
> at least 8.1)
> Customer: No, it is just that 8.2 is the current release
> CMD: True, but 8.3 is due out in the summer and 8.3 is a standard cycle
> release
> Customer: Oh... o.k. let's wait.
> CMD: I think that is probably prudent.
>
That's how it is with me. I upgraded to 8.1 from 7.4 because there was
nothing in 8.0 that I *needed* and performance was already more than
sufficient on my ridiculous overkill hardware. I recently upgraded from
8.1.x to 8.2.3 only because of the DST updates in Western Australia. I
would not have otherwise. If it ain't broke, don't fix it.

Furthermore, upgrading is inherently risky. There is always the chance
of human error induced downtime, and so doing it "just coz" is not a
prudent policy.

Finally, in the absence of security concerns or performance issues (and
I mean the "we can't afford to buy better hardware" type edge of the
envelope type issues) there is zero *need* to upgrade. Sure, it may be
better to use a new and shiny version, however I always favor a
realistic and honest assessment of *needs* over *perceived needs*.

All that being said, the older the version you are running, the higher
the weight that should be attributed to the "upgrading is a good idea
just coz" argument. After a point, upgrading is just a good idea "just
coz". I wouldn't recommend anyone continue to run 7.2.x merely because
it was working for them.

Just my 2c (adjusted for inflation).

Naz Gassiep <naz@mira.net> writes:
> Joshua D. Drake wrote:
>> Example discussion with customer:
> ...
> Finally, in the absence of security concerns or performance issues (and
> I mean the "we can't afford to buy better hardware" type edge of the
> envelope type issues) there is zero *need* to upgrade.

This line of argument ignores the fact that newer versions often contain
fixes for data-loss-grade bugs.  Now admittedly that is usually an
argument for updating to x.y.z+1 rather than x.y+1, but I think it
destroys any reasoning on the basis of "if it ain't broke".

            regards, tom lane

Not if you're not affected by the bugs.  Software *always* has bugs.
And new code in your environment is *untested* code in your environment.

If I am not affected by bugs, if I'm under a support contract to correct
any bugs that I *am* affected by (as was the case in Josh's original
argument with RHEL), and no new features are required, then all
upgrading will do is take me from a state of known bugs that don't
affect my systems to unknown bugs or undocumented/unintended changes
that *might* affect my systems.

The PostgreSQL community supports latest release.  Here, "upgrade to
most recent" exactly means "upgrade to the version we know has all the
fixes we've already done".  We ask people to upgrade here so we don't
have to reinvent the wheel just because someone wants to use 7.4.1.
Resources are tight enough just supporting the most recent codebase.
Including every codebase back to the beginning of time would require an
enormous number of people.

Support contracts with, for example, RHEL, don't necessarily work that
way.  They typically say "use our most recent packages; anything else is
not covered and you're on your own".  Because support contracts say
this, they have to maintain the codebase themselves to a fair extent.
Granted, they can just take the changes from -- in this case --
PostgreSQL's source code, but they are the people responsible for the
security of the code base and compatibility of the code base.  That's
*exactly* what you buy when you buy the support contract.

Look at it this way:
The benefits to any upgrade are "bug fix" and "new feature".
The caveats to any upgrade are "new bug" and "feature change".  (PHP and
MySQL are notorious for the latter.)

If "bug fix" is 100% handled by support contract, and "new feature" is
100% not useful, what is my impetus?

For a direct example, why should a business upgrade their desktops from
Windows XP to Windows Vista before 2011 if *none* of the new features
are needed?

--
Brandon Aiken
CS/IT Systems Engineer

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Wednesday, March 21, 2007 9:29 AM
To: Naz Gassiep
Cc: Joshua D. Drake; Erik Jones; CAJ CAJ; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Lifecycle of PostgreSQL releases

Naz Gassiep <naz@mira.net> writes:
> Joshua D. Drake wrote:
>> Example discussion with customer:
> ...
> Finally, in the absence of security concerns or performance issues
(and
> I mean the "we can't afford to buy better hardware" type edge of the
> envelope type issues) there is zero *need* to upgrade.

This line of argument ignores the fact that newer versions often contain
fixes for data-loss-grade bugs.  Now admittedly that is usually an
argument for updating to x.y.z+1 rather than x.y+1, but I think it
destroys any reasoning on the basis of "if it ain't broke".

            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

** LEGAL DISCLAIMER **
Statements made in this e-mail may or may not reflect the views and
opinions of Wineman Technology, Inc. or its employees.

This e-mail message and any attachments may contain legally privileged,
confidential or proprietary information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this e-mail
message is strictly prohibited. If you have received this message in
error, please immediately notify the sender and delete this e-mail
message from your computer.

> All that being said, the older the version you are running, the higher
> the weight that should be attributed to the "upgrading is a good idea
> just coz" argument. After a point, upgrading is just a good idea "just
> coz". I wouldn't recommend anyone continue to run 7.2.x merely because
> it was working for them.

Certainly, but 7.2 is considered EOL by the community and that is where
I would draw the line. When we fully EOL 7.3, we will make all customers
upgrade from that as well.

>
> Just my 2c (adjusted for inflation).
>

1.7mil?

Joshua D. Drake


>
> ---------------------------(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/

Tom Lane wrote:
> Naz Gassiep <naz@mira.net> writes:
>> Joshua D. Drake wrote:
>>> Example discussion with customer:
>> ...
>> Finally, in the absence of security concerns or performance issues (and
>> I mean the "we can't afford to buy better hardware" type edge of the
>> envelope type issues) there is zero *need* to upgrade.
>
> This line of argument ignores the fact that newer versions often contain
> fixes for data-loss-grade bugs.  Now admittedly that is usually an
> argument for updating to x.y.z+1 rather than x.y+1, but I think it
> destroys any reasoning on the basis of "if it ain't broke".

I think that we call pretty much assume that this whole thread is based
around the theory that we are all running the latest stable dot release
of whatever version. Which in fact does, mean "if it ain't broke, don't
fix it."


Sincerely,

Joshua D. Drake


>
>             regards, tom lane
>


--

      === 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/

>-----Original Message-----
>From: pgsql-general-owner@postgresql.org
>[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Brandon Aiken
>Sent: woensdag 21 maart 2007 15:25
>To: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] Lifecycle of PostgreSQL releases
>
[snip]
>Software *always* has bugs.

Sorry, couldn't resist...

Software Engineer: "My salary payments didn't get through this month, I
still haven't received any of you".
Accountant (former Software Engineer): "Sorry, our systems indicate that
your payment tripped a fatal bug in our payout software. That can
happen, you know, software has bugs after all. It's not problem, its
only a minor one. Well, we'll try again next month, maybe that works."

Could people for once treat bugs as unacceptable instead an accepted
thing?
(Especially people writing software for validating the software we are
writing is correct.)

As I said, I couldn't resist. Sorry...

- Joris

[snip]

Tom Lane wrote:
> Naz Gassiep <naz@mira.net> writes:
>
>> Joshua D. Drake wrote:
>>
>>> Example discussion with customer:
>>>
>> ...
>> Finally, in the absence of security concerns or performance issues (and
>> I mean the "we can't afford to buy better hardware" type edge of the
>> envelope type issues) there is zero *need* to upgrade.
>>
>
> This line of argument ignores the fact that newer versions often contain
> fixes for data-loss-grade bugs.  Now admittedly that is usually an
> argument for updating to x.y.z+1 rather than x.y+1, but I think it
> destroys any reasoning on the basis of "if it ain't broke".
Not when you consider that I did say "in the absence of security
concerns". I consider the possibility that a bug can cause me to lose my
data to be a "security concern". If it's a cosmetic bug or something
that otherwise does not affect a feature I use, then upgrading, as you
say, is very much of a x.y+1 wait than upgrading minor releases
sometimes multiple times a month.

It must be remembered that human error can result in downtime, which can
cost money. Therefore its a foo risk vs bar risk type balance. At least,
that's how I see it.

Naz Gassiep escribió:
> Tom Lane wrote:
>
> >This line of argument ignores the fact that newer versions often contain
> >fixes for data-loss-grade bugs.  Now admittedly that is usually an
> >argument for updating to x.y.z+1 rather than x.y+1, but I think it
> >destroys any reasoning on the basis of "if it ain't broke".
> Not when you consider that I did say "in the absence of security
> concerns". I consider the possibility that a bug can cause me to lose my
> data to be a "security concern". If it's a cosmetic bug or something
> that otherwise does not affect a feature I use, then upgrading, as you
> say, is very much of a x.y+1 wait than upgrading minor releases
> sometimes multiple times a month.

We don't do cosmetic fixes in minor versions.  All fixes are "security
concerns" per your definition above; though obviously not per most
people's definition, which is about crackers getting into their
machines, denials of service or other such problems.  Some minor
releases do not contain security fixes, but they do contain fixes for
data-loss-grade bugs, as Tom says.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Mar 21, 2007, at 10:10 AM, Bruce Momjian wrote:
> As the owner of a 1986 Toyota Celica, I can accept the argument that a
> newer car with slightly brighter paint might not be worth the switch.

Yup... that's why I drive a 1991 Acura.

Of course, there's also the fact that the NSX will do 180MPH... ;)

Ironically, it's actually getting some new paint over the next 2
weeks while I'm in New Zealand.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Jim Nasby wrote:
> On Mar 21, 2007, at 10:10 AM, Bruce Momjian wrote:
>> As the owner of a 1986 Toyota Celica, I can accept the argument that a
>> newer car with slightly brighter paint might not be worth the switch.
>
> Yup... that's why I drive a 1991 Acura.
>
> Of course, there's also the fact that the NSX will do 180MPH... ;)

Yes but do you have air conditioned AND heated seats, to fit any
occasion? ;)

Joshua D. Drake

>
> Ironically, it's actually getting some new paint over the next 2 weeks
> while I'm in New Zealand.
> --
> Jim Nasby                                            jim@nasby.net
> EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)
>
>
>
> ---------------------------(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/

Josh/Jim-

a ford truck will last just as long and you can get parts at any auto parts store in the US
the question is do you STILL have the original air freshener?

M-
--------------------------------------------------------------------------- 
This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is
addressedand may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you
arenot the intended recipient, you are notified that any dissemination, distribution or copying of this communication
isstrictly prohibited.
 
--------------------------------------------------------------------------- 
Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire
indiquéet peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce
document,nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire.
 
----- Original Message ----- 
From: "Joshua D. Drake" <jd@commandprompt.com>
To: "Jim Nasby" <decibel@decibel.org>
Cc: "Bruce Momjian" <bruce@momjian.us>; "Tom Lane" <tgl@sss.pgh.pa.us>; "Erik Jones" <erik@myemma.com>; "CAJ CAJ"
<pguser@gmail.com>;<pgsql-general@postgresql.org>
 
Sent: Saturday, March 24, 2007 11:45 PM
Subject: Re: [GENERAL] Lifecycle of PostgreSQL releases


> Jim Nasby wrote:
>> On Mar 21, 2007, at 10:10 AM, Bruce Momjian wrote:
>>> As the owner of a 1986 Toyota Celica, I can accept the argument that a
>>> newer car with slightly brighter paint might not be worth the switch.
>> 
>> Yup... that's why I drive a 1991 Acura.
>> 
>> Of course, there's also the fact that the NSX will do 180MPH... ;)
> 
> Yes but do you have air conditioned AND heated seats, to fit any 
> occasion? ;)
> 
> Joshua D. Drake
> 
>> 
>> Ironically, it's actually getting some new paint over the next 2 weeks 
>> while I'm in New Zealand.
>> -- 
>> Jim Nasby                                            jim@nasby.net
>> EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)
>> 
>> 
>> 
>> ---------------------------(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/
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

In article <73427AD314CC364C8DF0FFF9C4D693FF037A2F@nehemiah.joris2k.local>,
Joris Dobbelsteen <Joris@familiedobbelsteen.nl> wrote:

% Could people for once treat bugs as unacceptable instead an accepted
% thing?

It seems like you're responding to someone who's saying precisely
that he considers bugs unacceptable and doesn't want to introduce
them into a stable environment.

--

Patrick TJ McPhee
North York  Canada
ptjm@interlog.com