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

compatibilityissues from 7.1 to 7.4

P: n/a
I seem to remember reading a post on this, but searching marc does not
seem to bring it up immediately.

Company BBS is on postgresql, but it's still at 7.1. The guy in charge
of it wants some ballpark estimates and warnings about upgrading to 7.4
so he doesn't have to worry about the recent vulnerabilities.

War stories? Things to watch out for?

--
Joel <re**@ddcom.co.jp>
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Tue, 26 Oct 2004 18:22:55 +0900, Joel <re**@ddcom.co.jp> wrote:
I seem to remember reading a post on this, but searching marc does not
seem to bring it up immediately.

Company BBS is on postgresql, but it's still at 7.1. The guy in charge
of it wants some ballpark estimates and warnings about upgrading to 7.4
so he doesn't have to worry about the recent vulnerabilities.

War stories? Things to watch out for?


Off the top of my head: over-length data inserted into varchar fields
will no longer be silently truncated, raising an error instead ( a big
source of problems with web-based apps); also, the LIMIT x,y syntax
will no longer work.

Your best bet is fro someone who knows your system to go through the
PostgreSQL release notes.

Ian Barwick

---------------------------(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 23 '05 #2

P: n/a
On Tue, 26 Oct 2004 13:30:49 +0200
Ian Barwick <ba*****@gmail.com> wrote
On Tue, 26 Oct 2004 18:22:55 +0900, Joel <re**@ddcom.co.jp> wrote:
I seem to remember reading a post on this, but searching marc does not
seem to bring it up immediately.

Company BBS is on postgresql, but it's still at 7.1. The guy in charge
of it wants some ballpark estimates and warnings about upgrading to 7.4
so he doesn't have to worry about the recent vulnerabilities.

War stories? Things to watch out for?


Off the top of my head: over-length data inserted into varchar fields
will no longer be silently truncated, raising an error instead ( a big
source of problems with web-based apps); also, the LIMIT x,y syntax
will no longer work.

Your best bet is fro someone who knows your system to go through the
PostgreSQL release notes.


Thanks.

The guy in charge of this bbs is, of course, looking to avoid work
(don't we all), so he was wondering about whether 7.1 was subject to
this vulnerability and the possible data loss bug.

I did a little research, and it looks like 7.1.3 is the last of the 7.1
line. Security Focus reports a boundary condition vulnerability for
7.1.3 from 2003. So it doesn't look wise to leave it at 7.1 forever, I
suppose.

I'm looking at the release notes for 7.2 and thinking that, when we make
the jump, jumping to 7.4 will probably be the best bet.

Any other suggestions? Any thoughts on the urgency of the move?

--
Joel <re**@ddcom.co.jp>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #3

P: n/a
Joel <re**@ddcom.co.jp> writes:
Any thoughts on the urgency of the move?


How large is your pg_log file? 7.1 was the last release that had the
transaction ID wraparound limitation (after 4G transactions your
database fails...). If pg_log is approaching a gig, you had better
do something PDQ.

More generally: essentially all of the data-loss bugs we've fixed lately
existed also in 7.1. The core committee made a policy decision some
time ago that we wouldn't bother back-patching further than 7.2, however.
The only reason 7.2 is still getting some patching attention is that it
was the last pre-schema release, and so there might be some people out
there with non-schema-aware applications who couldn't conveniently move
up to 7.3 or later. But once 8.0 is out we'll probably lose interest in
supporting 7.2 as well.

regards, tom lane

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

Nov 23 '05 #4

P: n/a
On Thu, 28 Oct 2004 01:01:20 -0400
Tom Lane <tg*@sss.pgh.pa.us> wrote
Joel <re**@ddcom.co.jp> writes:
Any thoughts on the urgency of the move?
How large is your pg_log file? 7.1 was the last release that had the
transaction ID wraparound limitation (after 4G transactions your
database fails...). If pg_log is approaching a gig, you had better
do something PDQ.


Great. Very low use (to this point) BBS and similar things, so it looks
like we'll miss this issue.
More generally: essentially all of the data-loss bugs we've fixed lately
existed also in 7.1. The core committee made a policy decision some
time ago that we wouldn't bother back-patching further than 7.2, however.
The only reason 7.2 is still getting some patching attention is that it
was the last pre-schema release, and so there might be some people out
there with non-schema-aware applications who couldn't conveniently move
up to 7.3 or later. But once 8.0 is out we'll probably lose interest in
supporting 7.2 as well.


Thanks for the answers. I think we have good motivation to proceed.

--
Joel <re**@ddcom.co.jp>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #5

P: n/a
On Thu, Oct 28, 2004 at 10:35:27AM +0900, Joel wrote:

I'm looking at the release notes for 7.2 and thinking that, when we make
the jump, jumping to 7.4 will probably be the best bet.


Given that 7.2 is pretty much end of life now, I certainly wouldn't
adopt it. If you're going through the pain of upgrading, might as
well go all the way.

A

--
Andrew Sullivan | aj*@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.