Re: [HACKERS] 6.4.1 release - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] 6.4.1 release
Date
Msg-id 199812121509.AAA00526@ext16.sra.co.jp
Whole thread Raw
In response to Re: [HACKERS] 6.4.1 release  ("Pascal André" <andre@via.ecp.fr>)
List pgsql-hackers
> > > > 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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] 6.4.1 contrib/spi/
Next
From: Bruce Momjian
Date:
Subject: Re: Postgres for Sunos 4.1.4