Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Aleš Zelený <zeleny.ales@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-06-07T23:39:41Z
Lists: pgsql-bugs
Attachments
- bogus_fixeddecimal_hashfunc.diff (text/plain) patch
- robustify_memoize_code.patch (text/plain) patch
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
Commits
-
Harden Memoization code against broken data types
- cbcea3b91dcd 14.4 landed
- fa5185b26c45 15.0 landed