• Tom Lane's avatar
    Repair mishandling of cached cast-expression trees in plpgsql. · 0fc94a5b
    Tom Lane authored
    In commit 1345cc67, I introduced caching
    of expressions representing type-cast operations into plpgsql.  However,
    I supposed that I could cache both the expression trees and the evaluation
    state trees derived from them for the life of the session.  This doesn't
    work, because we execute the expressions in plpgsql's simple_eval_estate,
    which has an ecxt_per_query_memory that is only transaction-lifespan.
    Therefore we can end up putting pointers into the evaluation state tree
    that point to transaction-lifespan memory; in particular this happens if
    the cast expression calls a SQL-language function, as reported by Geoff
    Winkless.
    
    The minimum-risk fix seems to be to treat the state trees the same way
    we do for "simple expression" trees in plpgsql, ie create them in the
    simple_eval_estate's ecxt_per_query_memory, which means recreating them
    once per transaction.
    
    Since I had to introduce bookkeeping overhead for that anyway, I bought
    back some of the added cost by sharing the read-only expression trees
    across all functions in the session, instead of using a per-function
    table as originally.  The simple-expression bookkeeping takes care of
    the recursive-usage risk that I was concerned about avoiding before.
    
    At some point we should take a harder look at how all this works,
    and see if we can't reduce the amount of tree reinitialization needed.
    But that won't happen for 9.5.
    0fc94a5b
plpgsql.sql 109 KB