Re: Is it a memory leak in PostgreSQL 7.4beta?

On Sat, 30 Aug 2003, Stephan Szabo wrote:

> On Sat, 30 Aug 2003, Tom Lane wrote:
>
> > =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <hs(at)cybertec(dot)at> 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.

I rebuild without debug, and ran just the start/insert/commit sequence
over and over and noticed that on my machine it looked to grow as above
but that if I let it go long enough it seemed to basically stop (or at
least the growth was slow enough to go without notice as compared to the
easily noticable growth before). I'm running the full sequence now, but
it's going to be a while before it stops or gets up to the place where it
stoped in the s/i/c sequence.