Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] 6.4.1 release

From: "Pascal Andr" <andre(at)via(dot)ecp(dot)fr>
To: t-ishii(at)sra(dot)co(dot)jp
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 08:44:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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');
(1 row)

andre=> select lo_unlink(18465);
(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

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.


Pascal ANDRE, Internet and Media Consulting
"Use the source, Luke. Be one with the Code."    -- Linus Torvalds

In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 1998-12-12 15:09:22
Subject: Re: [HACKERS] 6.4.1 release
Previous:From: Thomas G. LockhartDate: 1998-12-12 04:02:38
Subject: Re: [HACKERS] JOIN syntax. Examples?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group