=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> The interesting thing was that my postmaster needed around 4mb of RAM
> when I started running my test script using ...
> After about 2 1/2 hours the backend process already needed 11mb of ram.
Hmm. I tried
create table t_data (data int4, ts timestamp default now());
followed by many repetitions of
START TRANSACTION ISOLATION LEVEL READ COMMITTED;
INSERT INTO t_data (data) VALUES ('2500');
UPDATE t_data SET data = '2500' WHERE data = '2500';
DELETE FROM t_data WHERE data = '2500';
COMMIT;
I am seeing a slow but steady growth of the backend process on a Linux
box (RHL 8.0) --- top shows it growing a few K every few seconds.
But I see *zero* growth with the same test on HPUX 10.20.
A possible wild card is that the Postgres build I'm using on the Linux
box is compiled for profiling (-pg, no --enable-debug or --enable-cassert)
whereas the HPUX build has --enable-debug and --enable-cassert but no
profiling. I'm not aware that there's any known memory leakage in
Linux' profiling support, though.
Can anyone else reproduce this, or confirm they don't see it? What
platform, and what configure options?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
