Обсуждение: 6.4.1 release
When are we doing it? With two development trees, we don't seem to have any motivation to release it. I think we should release 6.4.1 soon. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I think we should release 6.4.1 soon.
Well, portability bug reports and fixes still seem to be flowing in
at a great rate, so I don't think we can declare 6.4 frozen yet.
Maybe a 6.4.1 shortly to get the known problems, and expect 6.4.2
in another month or two?
regards, tom lane
>Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> I think we should release 6.4.1 soon.
>
>Well, portability bug reports and fixes still seem to be flowing in
>at a great rate, so I don't think we can declare 6.4 frozen yet.
>Maybe a 6.4.1 shortly to get the known problems, and expect 6.4.2
>in another month or two?
I think at least large object stuffs should be fixed(just a "select
lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
looking into codes for sometime but have not found complete fixes yet.
--
Tatsuo Ishii
t-ishii@sra.co.jp
> >Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> I think we should release 6.4.1 soon.
> >
> >Well, portability bug reports and fixes still seem to be flowing in
> >at a great rate, so I don't think we can declare 6.4 frozen yet.
> >Maybe a 6.4.1 shortly to get the known problems, and expect 6.4.2
> >in another month or two?
>
> I think at least large object stuffs should be fixed(just a "select
> lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> looking into codes for sometime but have not found complete fixes yet.
I thought we already had a large object fix in the two trees already?
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
On Thu, 10 Dec 1998, Tom Lane wrote:
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > I think we should release 6.4.1 soon.
>
> Well, portability bug reports and fixes still seem to be flowing in
> at a great rate, so I don't think we can declare 6.4 frozen yet.
> Maybe a 6.4.1 shortly to get the known problems, and expect 6.4.2
> in another month or two?
Works for me...let's say next Friday?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Thu, 10 Dec 1998, Tom Lane wrote: > > > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > > I think we should release 6.4.1 soon. > > > > Well, portability bug reports and fixes still seem to be flowing in > > at a great rate, so I don't think we can declare 6.4 frozen yet. > > Maybe a 6.4.1 shortly to get the known problems, and expect 6.4.2 > > in another month or two? > > Works for me...let's say next Friday? Cool. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > I think at least large object stuffs should be fixed(just a "select
> > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> > looking into codes for sometime but have not found complete fixes yet.
>
> I thought we already had a large object fix in the two trees already?
So you fixed inv_api.c? I got cvs header in REL6_4 tree (FreeBSD
2.2.6-RELEASE). Is this the latest one?
* $Header: /usr/local/cvsroot/pgsql/src/backend/storage/large_object/in\
v_api.c,v 1.41 1998/10/06 03:55:43 momjian Exp $
Following is a backend-crashing example. Any idea?
(/tmp/html.tar.gz is a 102458 bytes long file)
> select lo_import('/tmp/html.tar.gz');
blank 1: lo_import (typeid = 26, len = 4, typmod = -1, byval = t) ----
Program received signal SIGSEGV, Segmentation fault.
0x9dc75 in ReleaseBuffer ()
(gdb) where
#0 0x9dc75 in ReleaseBuffer ()
#1 0xa20b3 in inv_write ()
#2 0x4605f in lo_import ()
#3 0xd84a9 in fmgr_c ()
#4 0x3b06a in ExecMakeFunctionResult ()
#5 0x3b107 in ExecEvalFunc ()
#6 0x3b3c9 in ExecEvalExpr ()
#7 0x3b5e6 in ExecTargetList ()
#8 0x3b79a in ExecProject ()
#9 0x4139d in ExecResult ()
#10 0x39c66 in ExecProcNode ()
#11 0x392c6 in ExecutePlan ()
#12 0x38cf1 in ExecutorRun ()
#13 0xaad5b in ProcessQueryDesc ()
#14 0xaadc6 in ProcessQuery ()
#15 0xa8d8e in pg_exec_query_dest ()
#16 0xa8c24 in pg_exec_query ()
#17 0xaa598 in PostgresMain ()
#18 0x4c16c in main ()
(gdb)
> > Works for me...let's say next Friday?
Bruce, would you be willing to maintain a Status list for this minor
release? There are two or three patches floating around which would seem
to be candidates, and I suspect that there may be one or two things
someone (Tom Lane?) thinks I am looking at, but I'm not clear on what is
resolved and what is not.
So, a starting list:
Terry M.'s contrib addition
Tatsuo's Multi-Byte patches
Hiroshi's ParseComplexProject() patches(should include regression example?)
Constantin's PgAccess patches
Possible portability problems with PgAccess and Tcl-8.1
Size int4 -> size_t in c.h (put off 'til v6.5?)
Anything else?
- Tom
Thomas G. Lockhart wrote: > > > > Works for me...let's say next Friday? > > Bruce, would you be willing to maintain a Status list for this minor > release? There are two or three patches floating around which would seem > to be candidates, and I suspect that there may be one or two things > someone (Tom Lane?) thinks I am looking at, but I'm not clear on what is > resolved and what is not. > > So, a starting list: > > Terry M.'s contrib addition > Tatsuo's Multi-Byte patches > Hiroshi's ParseComplexProject() patches > (should include regression example?) > Constantin's PgAccess patches > Possible portability problems with PgAccess and Tcl-8.1 > Size int4 -> size_t in c.h (put off 'til v6.5?) > > Anything else? I'd like to see Jans 2 patches, the LIMIT one and the one that makes ORDER BY ose index if one is available (actually it omits the unnecessary sort node if possible). If you are unable to include them without regression tests, I can try to think out some; I guess the OR index patch is in CVS already. ------------ Hannu
> I'd like to see Jans 2 patches, the LIMIT one and the one that > makes ORDER BY ose index if one is available (actually it omits the > unnecessary sort node if possible). > > If you are unable to include them without regression tests, I can > try to think out some; > > I guess the OR index patch is in CVS already. Yes, the OR fix is in there. I need to look through my mailbox to see if there is anything else that needs applying. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tatsuo Ishii wrote:
> > > I think at least large object stuffs should be fixed(just a "select
> > > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> > > looking into codes for sometime but have not found complete fixes yet.
> >
> > I thought we already had a large object fix in the two trees already?
I thought I did. And in fact vanilla 6.4 (that include my patch; as I am not a
regular PostgreSQL developper, I did not set up SUP here) does not suffer the
specified bug (system is Linux 2.1.123/GNU libc 2; test-data is 121225 bytes long):
andre=> select lo_import('/tmp/test-data');
lo_import
--------- 18465
(1 row)
andre=> select lo_unlink(18465);
lo_unlink
--------- 1
(1 row)
> Following is a backend-crashing example. Any idea?
[ snip : backend crash, identical to test case abose, but ... crashing ]
That's quite similar to the previous problem. Did someone modify buffer handling
recently?
Tatsuo Ishii, could you try this surrounded with begin/end statements (and email me
the result of course) ? The large object buffer problem I corrected was partly
related to freed buffers at the automatic commit (at the end of the query path in
the backend, outside transactions). The fix was to release buffers earlier. It
would be helpful in order to understand the exact problem.
Thanks.
--
Pascal ANDRE, Internet and Media Consulting
andre@via.ecp.fr
"Use the source, Luke. Be one with the Code." -- Linus Torvalds
On Fri, 11 Dec 1998, Hannu Krosing wrote:
> Thomas G. Lockhart wrote:
> >
> > > > Works for me...let's say next Friday?
> >
> > Bruce, would you be willing to maintain a Status list for this minor
> > release? There are two or three patches floating around which would seem
> > to be candidates, and I suspect that there may be one or two things
> > someone (Tom Lane?) thinks I am looking at, but I'm not clear on what is
> > resolved and what is not.
> >
> > So, a starting list:
> >
> > Terry M.'s contrib addition
> > Tatsuo's Multi-Byte patches
> > Hiroshi's ParseComplexProject() patches
> > (should include regression example?)
> > Constantin's PgAccess patches
> > Possible portability problems with PgAccess and Tcl-8.1
> > Size int4 -> size_t in c.h (put off 'til v6.5?)
> >
> > Anything else?
>
> I'd like to see Jans 2 patches, the LIMIT one and the one that
> makes ORDER BY ose index if one is available (actually it omits the
> unnecessary sort node if possible).
v6.4.1 is a bug fix release, no extra features will be added...Jan
is planning on releasing a 'LIMIT-patch' after v6.4.1 so that if someone
wants it, its there, but it will not be in the standard distribution until
v6.5...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > > > I think at least large object stuffs should be fixed(just a "select
> > > > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> > > > looking into codes for sometime but have not found complete fixes yet.
> > >
> > > I thought we already had a large object fix in the two trees already?
>
> I thought I did. And in fact vanilla 6.4 (that include my patch; as I am not a
> regular PostgreSQL developper, I did not set up SUP here) does not suffer the
> specified bug (system is Linux 2.1.123/GNU libc 2; test-data is 121225 bytes long):
Linux boxes does not seem to have any problem with large object. As
far as I know, the bug appears on FreeBSD and Solaris/Sparc. I'm not
sure about other platforms.
> Tatsuo Ishii, could you try this surrounded with begin/end statements (and email me
>
> the result of course) ? The large object buffer problem I corrected was partly
> related to freed buffers at the automatic commit (at the end of the query path in
> the backend, outside transactions). The fix was to release buffers earlier. It
> would be helpful in order to understand the exact problem.
>
> Thanks.
Ok. Here are results.
o FreeBSD: surrounding with begin/end prevents backend-crash.
o Solaris: surrounding with begin/end does not help.
I guess there may be another bug that is different from the one you
mentioned. Solairs seems to be very "sensitive" to that kind of
problem?:-)
--
Tatsuo Ishii
> > > I think at least large object stuffs should be fixed(just a "select
> > > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> > > looking into codes for sometime but have not found complete fixes yet.
> >
> > I thought we already had a large object fix in the two trees already?
>
> So you fixed inv_api.c? I got cvs header in REL6_4 tree (FreeBSD
> 2.2.6-RELEASE). Is this the latest one?
>
> * $Header: /usr/local/cvsroot/pgsql/src/backend/storage/large_object/in\
> v_api.c,v 1.41 1998/10/06 03:55:43 momjian Exp $
>
> Following is a backend-crashing example. Any idea?
>
> (/tmp/html.tar.gz is a 102458 bytes long file)
>
> > select lo_import('/tmp/html.tar.gz');
> blank
> 1: lo_import (typeid = 26, len = 4, typmod = -1, byval = t)
> ----
Fixed. Since I re-designed the heap access API, the bug was crystal
clear as soon as I looked at the code. Scarry when I can figure out the
backend code so quickly.
Patch applied to both trees.
---------------------------------------------------------------------------
*** ./inv_api.c.orig Sun Dec 13 00:05:01 1998
--- ./inv_api.c Sun Dec 13 00:06:51 1998
***************
*** 549,556 **** tuplen = inv_wrnew(obj_desc, buf, nbytes - nwritten); else
tuplen= inv_wrold(obj_desc, buf, nbytes - nwritten, tuple, buffer); }
- ReleaseBuffer(buffer); /* move pointers past the amount we just wrote */ buf += tuplen;
--- 549,556 ---- tuplen = inv_wrnew(obj_desc, buf, nbytes - nwritten); else
tuplen= inv_wrold(obj_desc, buf, nbytes - nwritten, tuple, buffer);
+ ReleaseBuffer(buffer); } /* move pointers past the amount we just wrote */ buf
+=tuplen;
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> > > Works for me...let's say next Friday? > > Bruce, would you be willing to maintain a Status list for this minor > release? There are two or three patches floating around which would seem > to be candidates, and I suspect that there may be one or two things > someone (Tom Lane?) thinks I am looking at, but I'm not clear on what is > resolved and what is not. Only way to do it is cvs log, and run through my script, I get a nice log of changes. I will do it soon, now that I have cleaned out my mailbox of patches people wanted applied. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > > > I think at least large object stuffs should be fixed(just a "select
> > > > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> > > > looking into codes for sometime but have not found complete fixes yet.
> > >
> > > I thought we already had a large object fix in the two trees already?
> >
> > So you fixed inv_api.c? I got cvs header in REL6_4 tree (FreeBSD
> > 2.2.6-RELEASE). Is this the latest one?
> >
> > * $Header: /usr/local/cvsroot/pgsql/src/backend/storage/large_object/in\
> > v_api.c,v 1.41 1998/10/06 03:55:43 momjian Exp $
> >
> > Following is a backend-crashing example. Any idea?
> >
> > (/tmp/html.tar.gz is a 102458 bytes long file)
> >
> > > select lo_import('/tmp/html.tar.gz');
> > blank
> > 1: lo_import (typeid = 26, len = 4, typmod = -1, byval = t)
> > ----
>
> Fixed. Since I re-designed the heap access API, the bug was crystal
> clear as soon as I looked at the code. Scarry when I can figure out the
> backend code so quickly.
>
> Patch applied to both trees.
Thanks. Your patches definitely fix the problem on
FreeBSD. Unfotunately it does not help Solaris/Sparc. I'll look into
more on that platform.
---
Tatsuo Ishii
Marc G. Fournier wrote:
> On Fri, 11 Dec 1998, Hannu Krosing wrote:
>
> > I'd like to see Jans 2 patches, the LIMIT one and the one that
> > makes ORDER BY ose index if one is available (actually it omits the
> > unnecessary sort node if possible).
>
> v6.4.1 is a bug fix release, no extra features will be added...Jan
> is planning on releasing a 'LIMIT-patch' after v6.4.1 so that if someone
> wants it, its there, but it will not be in the standard distribution until
> v6.5...
As it is already in the v6.4-feature-patch you'll find in the
patches directory on ftp.
Does anyone have experience with the patch suppressing sort
on ORDER BY? If so and experiences are positive, I would also
give it a try and include it into the feature patch of
v6.4.1.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
The Hermit Hacker wrote: > > On Fri, 11 Dec 1998, Hannu Krosing wrote: > > > Thomas G. Lockhart wrote: > > > > > > > > Works for me...let's say next Friday? > > > > > > Bruce, would you be willing to maintain a Status list for this minor > > > release? There are two or three patches floating around which would seem > > > to be candidates, and I suspect that there may be one or two things > > > someone (Tom Lane?) thinks I am looking at, but I'm not clear on what is > > > resolved and what is not. > > > > > > So, a starting list: > > > > > > Terry M.'s contrib addition > > > Tatsuo's Multi-Byte patches > > > Hiroshi's ParseComplexProject() patches > > > (should include regression example?) > > > Constantin's PgAccess patches > > > Possible portability problems with PgAccess and Tcl-8.1 > > > Size int4 -> size_t in c.h (put off 'til v6.5?) > > > > > > Anything else? > > > > I'd like to see Jans 2 patches, the LIMIT one and the one that > > makes ORDER BY ose index if one is available (actually it omits the > > unnecessary sort node if possible). > > v6.4.1 is a bug fix release, no extra features will be added...Jan > is planning on releasing a 'LIMIT-patch' after v6.4.1 so that if someone > wants it, its there, but it will not be in the standard distribution until > v6.5... Aw... ;(p When not accepting the ORDER BY patch into 6.4 the explanation was that soon after 6.4 there will be a performance-enchancement release (no new features) called 6.4.1 for things like this. I guessed this would be the one. And for me the ORDER BY patch is actually a bugfix - it enables me to get at my huge table in a predictable order. Without the patch the same query used to kill the computer. (BTW, how could we test for such cases that exhaust some resources?we obviously can't include them in standard regressiontests) And, I don't need the LIMIT patch nearly as much as ORDER BY, I can do declare_cursor-move-fetch myself. It would still be very nice if moving past end would not render the cursor unusable. ----- Hannu