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

Large objects buffer leak

From: <andre(at)via(dot)ecp(dot)fr>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Large objects buffer leak
Date: 1998-07-16 14:59:33
Message-ID: Pine.LNX.3.96.980716164416.17513A-100000@Chimay (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

I wrote some time ago about a buffer leak appearing with PostgreSQL large
objects, calling for hints about where to look. As I did not get any
answer, I dived a little bit more in the code.

The problem is simple. For performance reasons (as far as I can tell), PG
large objects keep the object internal scan index open as long as the
object is not closed. The problem is that this index (may) keep pinned
In the CommitTransaction() function, these buffers are examined and
released if necessary, with an error notice. For long objects this causes
a segmentation fault in postmaster (and this is present in current public
Whenever all large objects operations are done inside a transaction (begin
- open lo - ... - close lo - end), this problem does not appear
(CommitTransaction() is only called on the END statement, when the index 
is closed).  

In order to correct this, I see two solutions:
  - close the index after every operation on large objects
  - clean up large objects opened indexes in CommitTransaction()
I prefer the second one, that offers speed-up inside transactions. But as
I do not know all the evolutions in progress, I would like to know which 
should be used in order to be coherent with the current works. 

Yet another question, does someone work on large objects ? If not, I can
code this bug fix and submit a patch.


Pascal ANDRE, graduated from Ecole Centrale Paris
"Use the source, Luke. Be one with the Code."  -- Linus Torvalds

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-07-16 15:27:11
Subject: Re: [HACKERS] [BUG?] strange PQgetisnull
Previous:From: Tom LaneDate: 1998-07-16 14:40:04
Subject: How about re-moderating pgsql-announce?

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