Re: strong memory leak in plpgsql from handled rollback and lazy cast

Pavel Stehule <pavel.stehule@gmail.com> writes:
> When I tested some hypothesis I wrote buggy code. It was surprise how fast
> I lost all free memory

> do $$
> begin
>   for i in 1..3000000
>   loop
>     begin
>       -- do some error
>       if i then end if;
>     exception when others then
>       -- do nothing
>     end;
>   end loop;
> end;
> $$;

Yeah, this is because an error gets thrown inside the cast-to-boolean.
It's intentional that the execution state tree gets thrown away if that
happens, per the comment in get_cast_hashentry:

     * Prepare the expression for execution, if it's not been done already in
     * the current transaction; also, if it's marked busy in the current
     * transaction, abandon that expression tree and build a new one, so as to
     * avoid potential problems with recursive cast expressions and failed
     * executions.  (We will leak some memory intra-transaction if that
     * happens a lot, but we don't expect it to.)  It's okay to update the

I'm not convinced that it'd be safe to re-use an ExprState after a
previous execution failed (though perhaps Andres has a different opinion?)
so I think the only way to avoid the intratransaction memory leak would
be to set up each new cast ExprState in its own memory context that we
could free.  That seems like adding quite a lot of overhead to get rid
of a leak that we've been living with for ages.

Maybe we could pay the extra overhead only after the expression has
failed at least once.  Seems a bit messy though, and I'm afraid that
we'd have to add PG_TRY overhead in any case.

            regards, tom lane