On Wed, 8 Jun 2022 at 07:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > So far, it looks that the query I've been using to prove the SIGSEV works
> > fine when I disabled jit by setting
> > jit=off
>
> Oh! So it's (probably) not a Memoize problem, it's an LLVM problem.
I wonder if Memoize should do a better job of handling lookup
failures. Before I knew the problem was with built-in datatypes, I
suspected this might have been caused by some extension with a broken
hash or equality function.
I decided to try writing a broken datatype by messing with the hash
function in [1] by patching it with the attached
bogus_fixeddecimal_hashfunc.diff then doing:
# create extension fixeddecimal;
# create table t1 (a fixeddecimal not null);
# insert into t1 select x%100 from generate_Series(1,10000)x;
# create index on t1(a);
# set work_mem=64;
# explain analyze select * from t1 inner join t1 t2 on t1.a=t2.a where t1.a<=2;
server closed the connection unexpectedly
If I patch it with the attached rebustify_memoize_code.patch, I get:
# explain analyze select * from t1 inner join t1 t2 on t1.a=t2.a where t1.a<=2;
ERROR: unable to find memoization table entry
My thoughts are that we likely should make this code more robust,
despite the bug not being related to a broken data type. I'm only just
over the fence on that one though. Any thoughts?
David
[1] https://github.com/2ndQuadrant/fixeddecimal