Thread

1. memory leak in date_part() function in v7.1beta3 ?

   Dirk Jagdmann <doj@cubic.org> — 2001-01-27T14:02:05Z

   Hello Developers,
   
   at first, thank you for the wonderful work you did on the excellent
   database.
   
   I was experimenting with the 7.1beta3 release. When I use the
   date_part() function in one query several thousand times (in updates for
   example) the postmaster consumes all available memory, until it dies,
   with a "no memory left error". If I execute the same queries without
   date_part() functions everything runs smooth.
   
   It assume that date_part() has a serious memory leak.
   
   If you like a can reproduce some queries that fail on my machine and
   send them to you with a second email.
   
   -- 
   --->
   ----> doj / cubic
   -----> http://www.cubic.org
   -----> http://llg.cubic.org
   
   

2. Re: memory leak in date_part() function in v7.1beta3 ?

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-27T19:16:50Z

   doj <doj@cubic.org> writes:
   > It assume that date_part() has a serious memory leak.
   > If you like a can reproduce some queries that fail on my machine and
   > send them to you with a second email.
   
   Yes, we need to see the exact sequence of queries ...
   
   			regards, tom lane
   
   

3. Re: memory leak in date_part() function in v7.1beta3 ?

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-29T00:47:17Z

   doj <doj@cubic.org> writes:
   > I was experimenting with the 7.1beta3 release. When I use the
   > date_part() function in one query several thousand times (in updates for
   > example) the postmaster consumes all available memory, until it dies,
   > with a "no memory left error". If I execute the same queries without
   > date_part() functions everything runs smooth.
   
   It turns out this is not specific to date_part(date); in fact, *all*
   SQL-language functions were leaking memory.  I have fixed the leaks
   exposed by this example and some related ones, but I suspect that
   some complex queries inside SQL functions will still leak a small
   amount of memory per execution.  We really need to reconsider how
   per-query data structures are allocated ... perhaps as part of the
   long-threatened querytree redesign.
   
   			regards, tom lane