"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 9/1/08, Marko Kreen <[EMAIL PROTECTED]> wrote:
>> First a correction, overriding malloc/free seems dangerous they
>> seems to leak out, so correct would be to use YYMALLOC/YYFREE.
>> This leaves 1.875 potentially leaking, but danger seems small.
> Her
On 9/1/08, Marko Kreen <[EMAIL PROTECTED]> wrote:
> First a correction, overriding malloc/free seems dangerous they
> seems to leak out, so correct would be to use YYMALLOC/YYFREE.
> This leaves 1.875 potentially leaking, but danger seems small.
Here is the safer patch. As the chance for the le
First a correction, overriding malloc/free seems dangerous they
seems to leak out, so correct would be to use YYMALLOC/YYFREE.
This leaves 1.875 potentially leaking, but danger seems small.
On 9/1/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > This means gra
Marko Kreen <[EMAIL PROTECTED]> writes:
> This means gram.y can leak memory if error is throws in
> the middle of parsing.
Please offer some evidence for that claim.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Currently gram.y uses malloc/free for memory management,
but all pointers are local to function. Unlike flex-based
scan.l which has static references to buffers and reuses them
across calls.
This means gram.y can leak memory if error is throws in
the middle of parsing.
The patch redefines malloc
