On Sat, 30 Aug 2003, Tom Lane wrote:
> =?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?
RHL9, --enable-debug, CFLAGS as -O0
Doing the above sequence many times from a script piped into psql, I'm
seeing RSS increasing for the backend as it goes along about the same as
yours it seems.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
