Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349

Hello,

I was able to reproduce the issue on the database restored to a test server.

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

The jit package is postgresql14-llvmjit-14.2-1PGDG.rhel7.x86_64

Having it reproducible on the test machine, I can test whatever you
instruct me to do to help to identify the root cause.

Kind regards Ales Zeleny

út 7. 6. 2022 v 10:29 odesílatel Aleš Zelený <zeleny(dot)ales(at)gmail(dot)com> napsal:

> Hello,
>
> The Cache Key plan part is:
> -> Memoize (cost=0.43..0.84
> rows=20 width=8)
> Cache Key: os1.date,
> os1.instrument_id
> -> Index Only Scan using
> outstanding_shares_instrument_id_date_key on outstanding_shares os2
> (cost=0.42..0.83 rows=20 width=8)
> Index Cond:
> ((instrument_id = os1.instrument_id) AND (date > os1.date))
>
> And the columns are:
> Table "outstanding_shares"
> Column | Type | Collation | Nullable |
> Default
>
> ---------------+---------+-----------+----------+---------------------------------------------------------
> instrument_id | integer | | |
> date | date | | not null |
>
> I have to check whether I can share full table structure, query and the
> query plan. In the meantime, the database was restored on a test machine,
> so I'll try to reproduce the issue.
>
> Kind regards Ales
>
> út 7. 6. 2022 v 5:17 odesílatel David Rowley <dgrowleyml(at)gmail(dot)com>
> napsal:
>
>> Thanks for reporting this.
>>
>> On Tue, 7 Jun 2022 at 13:21, PG Bug reporting form
>> <noreply(at)postgresql(dot)org> wrote:
>> > Program terminated with signal 11, Segmentation fault.
>> > #0 remove_cache_entry (entry=<optimized out>, mstate=<optimized out>)
>> at
>> > nodeMemoize.c:349
>>
>> The relevant line in 14.2 is:
>>
>> MemoizeKey *key = entry->key;
>>
>> So entry must be NULL here.
>>
>> cache_reduce_memory() just removes cache entries starting at the head
>> of the LRU. Given a correctly behaving hash function and equality
>> function I can't quite see how we could have something in the LRU list
>> that's not also stored in the hash table. The only two functions that
>> make changes to the hash table and LRU list are remove_cache_entry(),
>> cache_lookup() and cache_purge_all(). The latter of those 3 does not
>> really seem like a candidate for the hash table and list getting out
>> of sync given that it just creates an empty table and empty list.
>> That makes me suspect that either the hash function or equality
>> function for the data types in the cache key are misbehaving.
>>
>> Can you show us the EXPLAIN output for the problem query? Or at the
>> very least, the relevant "Cache Key" lines.
>>
>> And can you also show the psql \d output for the tables which are
>> mentioned in the cache key?
>>
>> I'm currently thinking that the Assert(entry != NULL) in
>> cache_reduce_memory() should probably be a runtime check rather than
>> an Assert. But let's wait to see if we can confirm that something
>> weird is going on with the cache key data type.
>>
>> David
>>
>