By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,372 Members | 1,906 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,372 IT Pros & Developers. It's quick & easy.

Upgrading from 7.2.3 to....??

P: n/a

Hi,

I was planning a major upgrade on our PostgreSQL system,
which is currently running PG 7.2.3 (on a Linux system)
to 7.3.4.

I see that version 7.4 just came out, with extremely
interesting and nice features! (kudos to PostgreSQL's
development team, BTW).

But of course, there's so much that it's new that I find
it kind of scary to upgrade straight to 7.4 (even though
the testing period was longer).

Since our upgrade will most likely take place early in
January, maybe by then we'll have a better idea about
how 7.4 performs in the real world, concerning stability/
reliability?

What would be your advice? Is 7.3.4 the recommended one
if we need reliability? Or has 7.4 earned sufficient
trust by now?

Also, how about back compatibility? Should I expect some
trouble? I remember with one of the previous upgrades
(I think it was from 7.1.* to 7.2.*), one of our SQL
statements stopped working, and it did it pretty silently
(i.e., the effect of the error would only be noticed under
certain conditions). After a while, we noticed the error,
and it was trivial to fix, but now it worries me now
whenever I have to upgrade to a new second-digit in the
version.

Thanks for any comments,

Carlos
--

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Sun, Nov 30, 2003 at 14:56:26 -0500,
Carlos Moreno <mo****@mochima.com> wrote:

Since our upgrade will most likely take place early in
January, maybe by then we'll have a better idea about
how 7.4 performs in the real world, concerning stability/
reliability?

What would be your advice? Is 7.3.4 the recommended one
if we need reliability? Or has 7.4 earned sufficient
trust by now?
You should go right to some version of 7.4. 7.4.1 should be out soon.
7.4 has a number of performance and maintainability features that you
don't want to miss. Going to 7.3 will be ablut as hard as going to 7.4,
so you might as well get the extra benefit.
Also, how about back compatibility? Should I expect some
trouble? I remember with one of the previous upgrades
(I think it was from 7.1.* to 7.2.*), one of our SQL
statements stopped working, and it did it pretty silently
(i.e., the effect of the error would only be noticed under
certain conditions). After a while, we noticed the error,
and it was trivial to fix, but now it worries me now
whenever I have to upgrade to a new second-digit in the
version.


Schemas are new in 7.3 and that might cause you to worry about them.
You can read through the release notes for 7.3 and 7.4 to look for
changes that might cause you problems.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #2

P: n/a
>>>>> "CM" == Carlos Moreno <mo****@mochima.com> writes:

CM> What would be your advice? Is 7.3.4 the recommended one
CM> if we need reliability? Or has 7.4 earned sufficient
CM> trust by now?

CM> Also, how about back compatibility? Should I expect some
CM> trouble? I remember with one of the previous upgrades

I just did that switch from 7.2 over to 7.4 this past weekend. It
went very smoothly. The major things to watch for that I found in the
history/release notes which were not very obvious were:

1) implicit converstion of empty string to numeric 0 is no longer
there. be sure you either specify numeric 0 or string '0' when you
mean that.

2) if you have default 'NOW()' (in quotes!) you have to change that to
default NOW() without quotes. Similar for other date/time default
thingies.

3) 7.2 used to nicely order your group by's implicitly. this is no
longer the case -- you must explicitly list any ordering you wish
imposed on group by's.

I think that was it. The speed seems to be faster, but that could
also be due to moving from a 4-disk RAID10 to a 14 disk RAID5 with
faster spindles ;-)

This is running my production site which does a *lot* of
inserts/updates daily. I'm very happy with it. You will be to :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #3

P: n/a

On Dec 3, 2003, at 1:05 PM, Vivek Khera wrote:
>> "CM" == Carlos Moreno <mo****@mochima.com> writes:


CM> What would be your advice? Is 7.3.4 the recommended one
CM> if we need reliability? Or has 7.4 earned sufficient
CM> trust by now?

CM> Also, how about back compatibility? Should I expect some
CM> trouble? I remember with one of the previous upgrades

I just did that switch from 7.2 over to 7.4 this past weekend. It
went very smoothly. The major things to watch for that I found in the
history/release notes which were not very obvious were:

....
The one thing that I've run across in that upgrade path is with
triggers. If you use:

Create or replace function trigger_foo()
returns opaque
....

It's going to change the function to return a trigger.
If you subsequently use the create or replace syntax and don't change
the return type to trigger (because you haven't updated your code), the
back end will refuse to replace the function complaining of a mismatch
in return types.

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

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.