Re: [rfc,patch] PL/Proxy in core

On 5/15/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
>  > On 5/15/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  >> "Marko Kreen" <markokr@gmail.com> writes:
>  >>> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
>  >>
>  >> It's not a leak because the memory can be re-used during the next
>  >> command.
>
>  > I may be blind, but I don't see any static variables there.
>
> Sorry, I was confusing bison with flex --- there are static variables
>  pointing at buffers within a flex scanner.
>
>  For bison it looks like defining YYSTACK_ALLOC/YYSTACK_FREE as
>  palloc/pfree might be a sane thing to do, but I haven't tested it.

Ok, so parser.y is now fine.

Now I must admit I do the same hack in scanner.l, but because it keeps
static references, there is always call to plproxy_yylex_destroy() in
places that throw exceptions (all of flex/bison/plproxy exceptions
go through single function).

Reason for that is again the fact that I could not wrap my brain around
flex memory handling.  And the hacks in src/backend/parser/scan.l are also
somethat mystery to me.  When using palloc() I can be sure of the flow,
and if something goes wrong it crashes instead leaking, so it can
be fixed immidately.

But now that I think about it, the scheme fails if palloc() itself
throws exception.  It can be fixed by calling following function
on parser entry:

void plproxy_yylex_startup(void)
{
#if FLXVER < 2005031(YY_CURRENT_BUFFER) = NULL;
#else(yy_buffer_stack) = NULL;
#endifplproxy_yylex_destroy();
}

This is pretty hairy, but anything near flex is hairy.  Such function
also would drop the requirement that plproxy_yylex_destroy() must always
be called.  Then we could keep current simple always-from-scratch allocation
pattern but more robust.


Or we could go back to default malloc usage.  I somewhat doubt it will
be much cleaner, it needs lot more faith in sanity of flex which I dont
have.
OTOH, considering that now here the possibility of others reviewing the
result is lot higher than before it can be attempted.

-- 
marko