Re: [HACKERS] 6.4.1 release

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: andre(at)via(dot)ecp(dot)fr
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] 6.4.1 release
Date: 1998-12-12 15:09:22
Message-ID: 199812121509.AAA00526@ext16.sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1998-12-12 17:31:27 Re: [HACKERS] Warning!!
Previous Message Pascal Andr 1998-12-12 08:44:18 Re: [HACKERS] 6.4.1 release