Thread

  1. Re: [HACKERS] Memory leaks?

    Maurice Gittens <mgittens@gits.nl> — 1998-02-13T11:51:55Z

    -----Original Message-----
    From: Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
    To: Maurice Gittens <mgittens@gits.nl>
    Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
    Date: vrijdag 13 februari 1998 18:36
    Subject: Re: [HACKERS] Memory leaks?
    
    
    >Maurice Gittens wrote:
    >> 
    >> Ok, I have an application which uses posgresql.
    >> 
    >> While testing the system (inserting many records into
    >> a database (with large objects) the system ran out of memory
    >> (the system has 64M RAM + 128M SWAP). Sorting the processes
    >> according to memory usage showed me a postgres process with 160M of
    >> memory (+-80%) used.
    >
    
    >Version ?
    >OS ?
    >INSERTs are inside BEGIN/END ? Was -DTBL_FREE_CMD_MEMORY used if YES and
    >version is < 6.3 ?
    >
    >Vadim
    
    Sorry, should have been more complete.
    
    - Postgresql Version:  6.3 (recent (this week) snapshop)
    - OS: Linux 2.0.33
    - INSERT's are within BEGIN/END brackets
    - TBL_FREE_CMD_MEMORY is defined in config.h (I guess it's the default).
    
    Hope this helps.
    
    
    
    
  2. Re: [HACKERS] Memory leaks?

    Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-13T12:31:50Z

    Maurice Gittens wrote:
    > 
    > - Postgresql Version:  6.3 (recent (this week) snapshop)
    > - OS: Linux 2.0.33
    > - INSERT's are within BEGIN/END brackets
    > - TBL_FREE_CMD_MEMORY is defined in config.h (I guess it's the default).
                                                            ^^^^^^^^^^^^^^^^ - in 6.3
    Well, this means that problem lies in large objects...
    I never used them... I assume that new relation and index
    is created for each LO. If this is right then we have memory leak
    in relation cache (heap_close doesn't flush relation from cache).
    Also, as I see now, LO interface uses its own memory context:
    TBL_FREE_CMD_MEMORY can't help here -> all allocation must be
    freed "manually".
    
    Unfortunately, I haven't time...
    
    Vadim