Re: ERROR: XX000: could not find memoization table entry (reproducible)

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Cc: Emmanuel Touzery <emmanuel(dot)touzery(at)plandela(dot)si>
Subject: Re: ERROR: XX000: could not find memoization table entry (reproducible)
Date: 2025-10-22 11:27:40
Message-ID: CAApHDvoodb6h0-ho_jV3Yi=Mcek3w6SjJuZykUQx+t+pbo-xzQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, 23 Oct 2025 at 00:16, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> To figure out why this is happening requires caffeination and staring
> at llvmjit_deform.c for a long time. I suspect whatever is in there
> that's meant to do what fetch_att() does isn't doing it the same way.

This code here:

LLVMValueRef v_tmp_loaddata;
LLVMTypeRef vartype = LLVMIntTypeInContext(lc, att->attlen * 8);
LLVMTypeRef vartypep = LLVMPointerType(vartype, 0);

v_tmp_loaddata =
LLVMBuildPointerCast(b, v_attdatap, vartypep, "");
v_tmp_loaddata = l_load(b, vartype, v_tmp_loaddata, "attr_byval");
v_tmp_loaddata = LLVMBuildZExt(b, v_tmp_loaddata, TypeDatum, "");

LLVMBuildStore(b, v_tmp_loaddata, v_resultp);

I don't speak this fluently by any means, but I think I see a zero
extension here up to the Datum width. That's not what fetch_att()
does.

Will look more tomorrow.

David

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ishan Arunkumar Joshi 2025-10-22 12:16:20 BUG #18942 and BUG #18938 solution available in Pg16 latest release 16.10
Previous Message David Rowley 2025-10-22 11:16:58 Re: ERROR: XX000: could not find memoization table entry (reproducible)