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

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
>