Re: SIGSEGV in dynahash

Hi,

> On PG19, ShmemInitHash always builds a fixed-size shared hash with a bump allocator (ShmemHashAlloc) whose alloc_arg is a stack-local region used only during hash_create. After init, that pointer is dead.
>
> In hash_search, for every HASH_ENTER / HASH_ENTER_NULL, dynahash does this before lookup:
>
> dynahash.cLines 927-937
> if (action == HASH_ENTER || action == HASH_ENTER_NULL)
> {
> if (hctl->freeList[0].nentries > (int64) hctl->max_bucket &&
> !IS_PARTITIONED(hctl) && !hashp->frozen &&
> !has_seq_scans(hashp))
> (void) expand_table(hashp);
> }
>
>
> It may cause SIGSEGV in case of using HASH_ENTER_NULL:
>
>
> hash_search(HASH_ENTER_NULL)
> → expand_table → seg_alloc → SIGSEGV in libc (MemSet/alloc)
>

The same thing cannot be triggered by
hash_search_with_hash_value()->get_hash_entry()->element_alloc()
because element_alloc()'s
if (hctl->isfixed) return false; guard trips before ever touching the allocator.

Similarly for dir_realloc() which has a check if
(hashp->hctl->max_dsize != NO_MAX_DSIZE) return false.
Since shared hash tables set a fixed max_dsize (not NO_MAX_DSIZE),
dir_realloc() returns false immediately instead of growing the
directory.

This makes me think we should add a check for hctl->isfixed in
seg_alloc() instead of before
expand_table() like it is done in the proposed patch.

It would also be valuable to add this SIGSEGV as a regression test. It
can't be triggered through any of the existing shared hash tables,
though — LOCK and PROCLOCK are the only fixed-size ones in core, and
both are partitioned, which makes expand_table() unreachable for them
(!IS_PARTITIONED(hctl) at dynahash.c:934/:1497). A dedicated
non-partitioned, fixed-size test hash table would be needed.

Thank you,
Rahila Syed