Thread: 7.1.4
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
Is there anything in the v7.1.x BRANCH that warrants a v7.1.4 release? 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 >
"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. Tidscan has been broken for 7.1.
2001-09-12 13:14 tgl
* src/backend/storage/lmgr/proc.c (REL7_1_STABLE): Back-patchdeadlock 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
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
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, > > 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