Re: [HACKERS] Memory leaks for large objects

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Peter T Mount <psqlhack(at)maidast(dot)demon(dot)co(dot)uk>
Cc: Maurice Gittens <mgittens(at)gits(dot)nl>, PostgreSQL-development <hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Memory leaks for large objects
Date: 1998-02-18 06:54:18
Message-ID: 34EA859A.848FB57D@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter T Mount wrote:

> On Mon, 16 Feb 1998, Maurice Gittens wrote:
>
> > Ok,
> >
> > I think large objects are leaking memory because the large object functions
> > in the backend use their own GlobalMemoryContext (called Filesystem), which
> > (according to a quick grep) is never freed.
> >
> > Supposing this is true and I ensure that the large object subsystem always
> > uses the current memory context for it's memory allocations.
> >
> > What might go wrong? (Or why did the designers decide to use a
> > GlobalMemoryContext for large objects?).
> >
> > I simple don't understand why one would create a special memory context
> > for large objects without some special reason.
> > Or should I just try it and see is anything breaks?
>
> I was wondering the same thing when I was looking at that part of the code
> a couple of months back. It would be interesting to see if anything did
> break.

Does the large object I/O persist across transactions? If so, then storage would
need to be outside of the usual context, which is reset after every transaction.
Is there a place where the large object context could be freed, but is not at
the moment?

- Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maurice Gittens 1998-02-18 07:07:36 Re: [HACKERS] Memory leaks for large objects
Previous Message Vadim B. Mikheev 1998-02-18 06:27:42 Re: stupid subselect core dumps