Feedback-ID: ia2694551:Fastmail
Date: Fri, 6 Oct 2023 12:01:05 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Erik Rijkers <er@xs4all.nl>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, jian he <jian.universality@gmail.com>
Subject: Re: remaining sql/json patches
Message-ID: <202310061001.ndbl6o4dl3zh@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+HiwqGGJtcVP=EGP0hH1Q6EqJE99KnOQvibC18QnepsWVu9fQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202310061001.ndbl6o4dl3zh%40alvherre.pgsql>
Precedence: bulk

On 2023-Oct-06, Amit Langote wrote:

> 2. Assignment of op->d.iocoerce.escontext needed to be changed like this:
> 
>                         v_params[4] = l_ptr_const(op->d.iocoerce.escontext,
> -
> l_ptr(StructErrorSaveContext));
> +                                                 l_ptr(StructNode));

Oh, so you had to go back to using StructNode in order to get this
fixed?  That's weird.  Is it just because InputFunctionCallSafe is
defined to take fmNodePtr?  (I still fail to see that a pointer to
ErrorSaveContext would differ in any material way from a pointer to
Node).


Another think I thought was weird is that it would only crash in LLVM5
debug and not the other LLVM-enabled animals, but looking closer at the
buildfarm results, I think that may have been only because you reverted
too quickly, and phycodorus and petalura didn't actually run with
7fbc75b26ed8 before you reverted it.  Dragonet did make a run with it,
but it's marked as "LLVM optimized" instead of "LLVM debug".  I suppose
that must be making a difference.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"World domination is proceeding according to plan"        (Andrew Morton)