From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Denis Perchine <dyp(at)perchine(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Small patch for memory leak in src/backend/catalog/pg_proc.c |
Date: | 2000-06-14 04:52:38 |
Message-ID: | 200006140452.AAA23321@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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(at)perchine(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2000-06-14 13:13:09 | Re: Big 7.1 open items |
Previous Message | Bruce Momjian | 2000-06-14 03:19:19 | Re: Patch 0.2 for Re: [HACKERS] Caching number of blocks in relation to avoi lseek. |