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
validityby * 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
donealready 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
