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

On 5/15/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Marko Kreen" <markokr(at)gmail(dot)com> writes:
> > On 5/15/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> "Marko Kreen" <markokr(at)gmail(dot)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;
#endif
plproxy_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