7.1.4

Is there anything in the v7.1.x BRANCH that warrants a v7.1.4 release?

On Thu, 24 Jan 2002, Justin Clift wrote:

"Marc G. Fournier" wrote:

Is there anything in the v7.1.x BRANCH that warrants a v7.1.4 release?

Hi Marc,

I'm not sure, I'm just thinking about the few bugs which have trickled
through about 7.1.3, and Tom's email a while ago saying that heaps of
the bugs which had been fixed were 7.1.3 ones.

It's a feeling, not an educated "taken a close look at it" thing.

Regards and best wishes,

Justin Clift

On Thu, 24 Jan 2002, Justin Clift wrote:

Hi guys,

Sorry to say this, but I'm feeling we're getting near to needing a
7.1.4.

A lot of places won't upgrade to 7.2 final until a few bug-fix point
releases are out the door anyway, and we all know that 7.1.3 is pretty
good.

Do the Hackers think we've got time to generate a further bugfix release
of 7.1.x, as it will still probably be in real-world production use for
quite some time?

:-)

Regards and best wishes,

Justin Clift

-------- Original Message --------
Subject: [GENERAL] Problem with btree index on 7.1.3
Date: Thu, 24 Jan 2002 15:14:11 +0600
From: Denis Perchine <dyp@perchine.com>
Organization: AcademSoft Ltd.
To: pgsql-general@postgresql.org

Hello,

on 7.1.3 I get:
ERROR: btree: index item size 3028 exceeds maximum 2713

it seems like known problem, and I have a feeling that it is fixed in
7.2 RC1,
but does anywhere a patch available for 7.1.3?

--
Denis

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

http://www.postgresql.org/users-lounge/docs/faq.html

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

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

"Marc G. Fournier" <scrappy@hub.org> writes:

Is there anything in the v7.1.x BRANCH that warrants a v7.1.4 release?

According to CVS, the *only* stuff in the 7.1 branch since 7.1.3 is

2001-10-01 05:38 inoue

* src/: backend/executor/nodeTidscan.c, include/nodes/execnodes.h
(REL7_1_STABLE): Keep the contents of TIDs not the pointers. Tid
scan has been broken for 7.1.

2001-09-12 13:14 tgl

* src/backend/storage/lmgr/proc.c (REL7_1_STABLE): Back-patch
deadlock recovery fix into 7.1 tree, in case someone needs it.

The deadlock-recovery fix is somewhat interesting, but I hardly think it
warrants a 7.1.4.

There are other fixes in current sources that perhaps could be
back-patched if we wanted to expend the time to do it. I don't...

regards, tom lane

Justin Clift <justin@postgresql.org> writes:

I'm not sure, I'm just thinking about the few bugs which have trickled
through about 7.1.3, and Tom's email a while ago saying that heaps of
the bugs which had been fixed were 7.1.3 ones.

Trouble is, we mostly haven't bothered to back-patch the fixes. Putting
out a 7.1.4 would involve going through the CVS logs, figuring out which
entries represented fixes for old bugs that deserve back-patching, and
then applying the patch (possibly after changes to get it to apply
against the older code). This'd be a huge amount of work --- cvs2cl
reports more than a thousand separate commits since last September, so
even trolling the log would be a significant effort. Testing the end
result would be a problem too...

regards, tom lane

Tom Lane wrote:

"Marc G. Fournier" <scrappy@hub.org> writes:

Is there anything in the v7.1.x BRANCH that warrants a v7.1.4 release?

<snip

The deadlock-recovery fix is somewhat interesting, but I hardly think it
warrants a 7.1.4.

There are other fixes in current sources that perhaps could be
back-patched if we wanted to expend the time to do it. I don't...

Was a thought. :)

Regards and best wishes,

Justin Clift

regards, tom lane

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Tom,

I'm not sure, I'm just thinking about the few bugs which have trickled
through about 7.1.3, and Tom's email a while ago saying that heaps of
the bugs which had been fixed were 7.1.3 ones.

Trouble is, we mostly haven't bothered to back-patch the fixes. Putting
out a 7.1.4 would involve going through the CVS logs, figuring out which
entries represented fixes for old bugs that deserve back-patching, and
then applying the patch (possibly after changes to get it to apply
against the older code). This'd be a huge amount of work --- cvs2cl
reports more than a thousand separate commits since last September, so
even trolling the log would be a significant effort. Testing the end
result would be a problem too...

This is nice. But I hope that you are agree that it is not a good idea
to switch production system to RC1 version. A bug I mentioned is a real
problem. Is it possible that it will be addressed? I could do this myself,
but as far as I remember the fix was done by you, and was quite large.

--
Denis

On Fri, 25 Jan 2002, Denis Perchine wrote:

This is nice. But I hope that you are agree that it is not a good idea
to switch production system to RC1 version. A bug I mentioned is a real
problem. Is it possible that it will be addressed? I could do this
myself, but as far as I remember the fix was done by you, and was quite
large.

Actually, I'm running a couple of production databases on a v7.2beta ...
one of them is quite heavily pounded to, as its used for logging and stats
for a FreeBSD Firewall bridging between the Internet and a B-Class network
... hasn't failed me yet, and its been in production since before Xmas
due to the "VACUUM doesn't lock tables" addition ...

Denis Perchine <dyp@perchine.com> writes:

This is nice. But I hope that you are agree that it is not a good idea
to switch production system to RC1 version.

*Somebody* has got to make that leap of faith, you know. Do you think
it magically gets more reliable when we slap a different label on it?
The way it gets more reliable is that people use it.

A bug I mentioned is a real
problem. Is it possible that it will be addressed? I could do this myself,
but as far as I remember the fix was done by you, and was quite large.

If it was a large fix then I'd be unlikely to regard it as safe to
back-patch into 7.1.* anyway. Why do you think that 7.1.3 + a whole
bunch of poorly-tested bugfixes would be safer to put into production
than RC1? RC1 has at least seen a fair amount of usage as an integrated
whole. A 7.1.4 with any but the most simple, obviously correct fixes
would not be more trustworthy in my eyes --- at least not till after it
had seen field testing. So people who think as you suggest wouldn't
update anyway.

If you are running into a 7.1 bug that is fixed in 7.2, then I would say
that for your purposes 7.2 is already more stable than 7.1. You should
be planning to update ASAP, not asking the developers to expend large
amounts of not-very-productive work so that you can avoid updating.

regards, tom lane