Hi, While hacking a bit more on my JIT prototype (so I actually know what I'm talking about at pgcon), I encountered an interesting issue. To keep track of the lifetime of JITed functions it seems natural to add support for that to resowners. Not that hard.
After doing so, I got pretty weird crashes. A bit of debugging later it became apparent that the issue is in how plpgsql caches expression states: typedef struct PLpgSQL_expr { ... * if expr is simple AND prepared in current transaction, * expr_simple_state and expr_simple_in_use are valid. Test validity by * seeing if expr_simple_lxid matches current LXID. (If not, * expr_simple_state probably points at garbage!) */ ExprState *expr_simple_state; /* eval tree for expr_simple_expr */ bool expr_simple_in_use; /* true if eval tree is active */ LocalTransactionId expr_simple_lxid; ... which we test in functions like exec_eval_simple_expr like: /* * Prepare the expression for execution, if it's not been done already in * the current transaction. (This will be forced to happen if we called * exec_simple_recheck_plan above.) */ if (expr->expr_simple_lxid != curlxid) which means we'll re-use ExprStates built in another subtransaction. In the case causing trouble, the ExprState has been built in another subtransaction, that subxact has been aborted, and thus the function released. And to make it even more confusing, in the case I noticed first the memory had since been reused by a *different* function :/. Is it really intentional that plpgsql uses ExprStates built in aborted subtransactions? It seems to mostly work because the cache invalidations triggered by the subabort trigger replans in many cases, but I'm very doubtful that's complete. It's easy enough to "solve" in the case of JIT by only releasing functions at eoxact, by reassigning them upwards, but that doesn't strike me as a nice approach. Comments? Ideas? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers