Horton

Thread

  1. 7.1.4

    Justin Clift <justin@postgresql.org> — 2002-01-24T10:01:29Z

    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

  2. Re: 7.1.4

    Marc G. Fournier <scrappy@hub.org> — 2002-01-24T13:21:31Z

    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
>

  3. Re: 7.1.4

    Justin Clift <justin@postgresql.org> — 2002-01-24T14:57:44Z

    "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

  4. Re: 7.1.4

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-01-24T14:57:57Z

    "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

  5. Re: 7.1.4

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-01-24T15:43:10Z

    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

  6. Re: 7.1.4

    Justin Clift <justin@postgresql.org> — 2002-01-24T15:50:05Z

    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

  7. Re: 7.1.4

    Denis Perchine <dyp@perchine.com> — 2002-01-24T18:28:14Z

    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

  8. Re: 7.1.4

    Marc G. Fournier <scrappy@hub.org> — 2002-01-24T18:47:37Z

    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 ...

  9. Re: 7.1.4

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-01-24T18:57:34Z

    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