Thread: Small patch for memory leak in src/backend/catalog/pg_proc.c

Hello all,

Someone just forget to free tuple after heap_insert.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Denis Perchine <dyp@perchine.com> writes:
***************
*** 327,331 ****
--- 327,332 ----
          CatalogCloseIndices(Num_pg_proc_indices, idescs);
      }
      heap_close(rel, RowExclusiveLock);
+     heap_freetuple(tup);
      return tup->t_data->t_oid;
  }

Uh, you didn't notice that the tuple you just freed is still in use
on the next line?

Memory leaks like this are not worth worrying about because the memory
will be reclaimed at end of transaction --- maybe even sooner after
I improve the memory-context handling.

            regards, tom lane

>       heap_close(rel, RowExclusiveLock);
> +     heap_freetuple(tup);
>       return tup->t_data->t_oid;
>   }
>
> Uh, you didn't notice that the tuple you just freed is still in use
> on the next line?

That's right :-((( Will try to be a little bit more accurate.

> Memory leaks like this are not worth worrying about because the memory
> will be reclaimed at end of transaction --- maybe even sooner after
> I improve the memory-context handling.

But anyway it is better to free memory, because transaction can be quite large.
New patch attached.

BTW, could you please say what memory leaks can be safely ignored.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

> But anyway it is better to free memory, because transaction can be quite large.
> New patch attached.

:-((( Again small mistake.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Applied.

> > But anyway it is better to free memory, because transaction can be quite large.
> > New patch attached.
>
> :-((( Again small mistake.
>
> --
> Sincerely Yours,
> Denis Perchine
>
> ----------------------------------
> E-Mail: dyp@perchine.com
> HomePage: http://www.perchine.com/dyp/
> FidoNet: 2:5000/120.5
> ----------------------------------

[ Attachment, skipping... ]
Index: pg_proc.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/catalog/pg_proc.c,v
retrieving revision 1.43
diff -c -b -w -r1.43 pg_proc.c
*** pg_proc.c    2000/05/28 17:55:54    1.43
--- pg_proc.c    2000/06/13 15:31:57
***************
*** 67,72 ****
--- 67,73 ----
      Oid            toid;
      NameData    procname;
      TupleDesc    tupDesc;
+     Oid        retval;

      /* ----------------
       *    sanity checks
***************
*** 327,331 ****
          CatalogCloseIndices(Num_pg_proc_indices, idescs);
      }
      heap_close(rel, RowExclusiveLock);
!     return tup->t_data->t_oid;
  }
--- 328,334 ----
          CatalogCloseIndices(Num_pg_proc_indices, idescs);
      }
      heap_close(rel, RowExclusiveLock);
!     retval = tup->t_data->t_oid;
!     heap_freetuple(tup);
!     return retval;
  }


--
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026