Hi, On Tue, Jul 19, 2022 at 4:09 AM Andrew Dunstan <and...@dunslane.net> wrote: > On 2022-07-15 Fr 17:07, Andres Freund wrote: > > Perhaps you could post your current state? I might be able to help resolving > > some of the problems. > > Ok. Here is the state of things. This has proved to be rather more > intractable than I expected. Almost all the legwork here has been done > by Amit Langote, for which he deserves both my thanks and considerable > credit, but I take responsibility for it. > > I just discovered today that this scheme is failing under > "force_parallel_mode = regress". I have as yet no idea if that can be > fixed simply or not.
The errors Andrew mentions here had to do with a bug of the new coercion evaluation logic. The old code in ExecEvalJsonExpr() would skip coercion evaluation and thus also the sub-transaction associated with it for some JsonExprs that the new code would not and that didn't sit well with the invariant that a parallel worker shouldn't try to start a sub-transaction. That bug has been fixed in the attached updated version. > Apart from that I think the main outstanding issue > is to fill in the gaps in llvm_compile_expr(). About that, I was wondering if the blocks in llvm_compile_expr() need to be hand-coded to match what's added in ExecInterpExpr() or if I've missed some tool that can be used instead? -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
v2-0002-Evaluate-various-JsonExpr-sub-expressions-using-p.patch
Description: Binary data
v2-0003-Use-one-ExprState-to-implement-JsonItemCoercions.patch
Description: Binary data
v2-0001-in-JsonExprState-just-store-a-pointer-to-the-inpu.patch
Description: Binary data
