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

Re: [HACKERS] Memory leaks for large objects

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: mgittens(at)gits(dot)nl (Maurice Gittens)
Cc: hackers(at)postgreSQL(dot)org (PostgreSQL-development)
Subject: Re: [HACKERS] Memory leaks for large objects
Date: 1998-03-16 05:10:39
Message-ID: 199803160510.AAA22528@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Added to TODO list.

> 
> >
> >Large object have been broken for quite some time.  I say remove the
> >memory context stuff and see what breaks.  Can't be worse than earlier
> >releases, and if there is a problem, it will show up for us and we can
> >issue a patch.
> >
> >--
> 
> 
> I insured that all memory allocations in be-fsstubs.c used the
> current memorycontext for their allocations.
> The system encounters errors when opening large objects which
> were just created. Message like: "ERROR cannot open xinv<number>".
> This happens even though all large_object operations are performed
> in a transaction.
> 
> I'm now wondering wether in the approach above the files associated
> with the large object will ever be freed (Or will de virtual file descriptor
> stuff
> handle this?).
> 
> Might it be so that because large objects and are implemented using
> relations/indexes that information about these must persist until these
> are properly closed by the postgres system?
> 
> How about not changing anything except adding a lo_garbage_collect function,
> which frees the MemoryContext used by large objects and does any other
> work needed? (Like closes indexes/relations?).
> 
> Thanks,
> Maurice
> 
> 
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-03-16 05:37:00
Subject: Re: [HACKERS] Subselects are in CVS...
Previous:From: Bruce MomjianDate: 1998-03-16 05:09:01
Subject: Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs

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