Re: PG 11 JIT deform failure

Hi,

I searched the mailing list but found nothing. Any reason why
TupleDescAttr is a macro and not a static inline?

Rather than adding an Assert attached POC replace TupleDescAttr macro
by a static inline function with AssertArg.
It:
- Factorize Assert.

- Trigger an Assert in JIT_deform if natts is wrong.

- Currently In HEAD
src/backend/access/common/tupdesc.c:TupleDescCopyEntry() compiler can
optimize out AssertArg(PointerIsValid(...)), no idea
if compiling with both cassert and -O2 make sense though).

- Remove two UB in memcpy when natts is zero.

Note:
Comment line 1480 in ../contrib/tablefunc/tablefunc.c is wrong it's
the fourth column.

Regards
Didier

On Thu, Jun 13, 2019 at 8:35 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On June 13, 2019 11:08:15 AM PDT, didier <did447(at)gmail(dot)com> wrote:
> >Extensions can do it, timescaledb in this case with:
> >INSERT INTO ... RETURNING *;
> >
> >Or replacing the test in llvm_compile_expr with an Assert in
> >slot_compile_deform ?
>
> In that case we ought to never generate a deform expression step - core code doesn't afair. That's only done I'd there's actually something to deform. I'm fine with adding an assert tough
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.