Re: PG 11 JIT deform failure

From: Andres Freund <andres(at)anarazel(dot)de>
To: didier <did447(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 11 JIT deform failure
Date: 2019-07-17 22:32:53
Message-ID: 20190717223253.2zc4lepn64uc4l7k@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I still haven't heard an explanation why you see a problem here.

On 2019-06-27 15:54:28 +0200, didier wrote:
> I searched the mailing list but found nothing. Any reason why
> TupleDescAttr is a macro and not a static inline?

It's present in branches that can't rely on static inlines being
present. Obviously we can still change it in HEAD, because there we rely
on static inlien functions working (althoug we might need to surround it
with #ifndef FRONTEND, if tupdesc.h is included from other headers
legitimately needed from frontend code).

> 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).

It's not important.

> - Remove two UB in memcpy when natts is zero.

I don't think it matters, but I'm not actually sure this is actually
UB. It's IIRC legal to form a pointer to one after the end of an array
(but not dereference, obviously), and memcpy with a 0 length byte also
is legal.

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

Huh, this is of very long-standing vintage. Think it's been introduced
in

commit a265b7f70aa01a34ae30554186ee8c2089e035d8
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: 2003-07-27 03:51:59 +0000

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-17 22:42:07 New "-b slim" option in 2019b zic: should we turn that on?
Previous Message Alvaro Herrera 2019-07-17 22:30:37 Re: getting ERROR "relation 16401 has no triggers" with partition foreign key alter