In commit 0fc94a5ba I wrote: + * ... It's okay to update the [ session-wide ] + * hash table with the new tree because all plpgsql functions within a + * given transaction share the same simple_eval_estate.
Um. Well, that's true for actual functions, but plpgsql DO blocks use their own private simple_eval_estate. That means that after a DO block runs, the cast_hash contains dangling pointers to expression eval state trees, which a subsequent plpgsql execution in the same transaction will think are still valid. Ooops. (See bug #13571.) The simplest fix for this would be to give up on the idea that DO blocks use private simple_eval_estates, and make them use the shared one. However, that would result in intra-transaction memory bloat for transactions executing large numbers of DO blocks; see commit c7b849a89, which installed that arrangement to begin with. Since that change was based on a user complaint, this answer doesn't seem appetizing. Or we could try to use the shared simple_eval_estate for CAST expressions even within DO blocks, but I'm afraid that would break things in subtle ways. We need to do actual execution in the block's own eval_estate, or we will have problems with leakage of pass-by-reference cast results because exec_eval_cleanup() won't know to clean them up. It's possible that we could get away with putting the expression state tree into the shared simple_eval_estate's per-query memory and then executing it with the block's private simple_eval_estate, but I'm afraid there are probably places in execQual and/or C functions that suppose that the expression state tree is in the estate's per-query memory. (That is, I doubt that we're totally consistent about whether we use fcinfo->flinfo->fn_mcxt or econtext->ecxt_per_query_memory for long-lived data, in which case an arrangement like this could lead to dangling pointers.) Or we could change things so that DO blocks use private cast_hash hashtables along with their private simple_eval_estates. This would give up some efficiency (since a DO block would then always need to do its own cast lookups) but it would be a simple and reliable fix. I'm kind of inclined to go with the last choice, but I wonder if anyone wants to argue differently, or sees another feasible solution. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers