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

-----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.

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

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...

OK, part of the problem might be the lo_create function which
creates a large object using the functions inv_create and
inv_close.

inv_create uses TupleDescInitEntry to create tuple descriptors (I think)
but it never seems to free these tuple descriptors.

The function FreeTupleDesc seems to have been created for this purpose.
As I'm new to postgresql this I'm wondering if I'm on the right track.

Anyway I'll give it a try and see if the problem goes a way.

Regards,
Maurice

unsubscribe gerhardr@tech-edv.co.at
end