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@gmail.com> napsal:

Thanks for reporting this.

On Tue, 7 Jun 2022 at 13:21, PG Bug reporting form
<noreply@postgresql.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