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, Pennsylvania 19026

Thu, 10 Dec 1998 14:16:14 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
6.4.1 release
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

Thu, 10 Dec 1998 21:43:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.4.1 release 
>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

Fri, 11 Dec 1998 11:58:46 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] 6.4.1 release 
> >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, Pennsylvania 19026

Thu, 10 Dec 1998 23:16:36 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.4.1 release
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 


Fri, 11 Dec 1998 02:15:49 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.4.1 release 
> 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, Pennsylvania 19026

Fri, 11 Dec 1998 01:38:25 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.4.1 release
> > 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)

Fri, 11 Dec 1998 23:43:27 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] 6.4.1 release 
> >       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

Fri, 11 Dec 1998 15:21:27 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] 6.4.1 release
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

Fri, 11 Dec 1998 18:02:51 +0200
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] 6.4.1 release
> 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, Pennsylvania 19026

Fri, 11 Dec 1998 11:25:53 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.4.1 release


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



Sat, 12 Dec 1998 09:44:18 +0100
"Pascal Andr���" <andre@via.ecp.fr>
Re: [HACKERS] 6.4.1 release
> > > > 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

Sun, 13 Dec 1998 00:09:22 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] 6.4.1 release 
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 


Sat, 12 Dec 1998 16:06:22 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.4.1 release
> > > 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, Pennsylvania 19026

Sun, 13 Dec 1998 00:10:46 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.4.1 release
> > >       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, Pennsylvania 19026

Sun, 13 Dec 1998 00:12:08 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.4.1 release
> > > > 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

Sun, 13 Dec 1998 20:14:37 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] 6.4.1 release 
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) #



Mon, 14 Dec 1998 10:23:40 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] 6.4.1 release
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 regression tests)

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

Mon, 14 Dec 1998 20:49:22 +0200
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] 6.4.1 release