compatibilityis sues from 7.1 to 7.4

[Joel]

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 YourEmailAddres sHere" to ma*******@postg resql.org)

[Ian Barwick]

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

[Joel]

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

[Tom Lane]

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

[Joel]

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

[Andrew Sullivan]

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*@crankycanuc k.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*******@postg resql.org so that your
message can get through to the mailing list cleanly