Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349
От | David Rowley |
---|---|
Тема | Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349 |
Дата | |
Msg-id | CAApHDvpxFSTwvoYWT7kmFVSZ9zLAeHb=S9vrz=RExMgSkQNWqw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349
|
Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: