Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash

On Thu, Oct 08, 2026 at 12:00:34PM -0500, Sami Imseih wrote:
> For example if a custom stats extension is removed from config. In that case
> kind_hash[kind] is NULL, and this would dereference it before
> missing_ok is reached.
> I changed this to return true when missing_ok is set, and ERROR
> otherwise. I could not find any other paths that need this handling.
>
> Of course, there is also the alternate case where we associate a kind
> id with a completely
> different kind on startup, and in that case, it's ok to drop the
> entries. All WAL/2PC records
> store is a kind_id, and I don't think we need anything more complex.

I'm halfly fine regarding this line of argument. Checking that the
kind_hash is assigned for the kind ID in the record and failing (or
silently skip if missing_ok is set) sounds fine. But the kind ID has
no need to be bound to a hard check: WAL records are protected by a
CRC, meaning that an incorrect kind ID would come from the origin, and
we trust the origin, being the WALs themselves.

> v6-0002:
>
> 4/ The existing TAP test was missing the own_hash column.

The tests used duplicated descriptions across the loop, so I have
appended a $kind_name. A second thing that felt missing was a query
on pg_stat_kind_info to check that own_hash is set, once for each
loop. It's true that v6 included something at the top, but only
covered that own_hash=false, and not the second mode.

I have done another pass, adjusting a few things on the way, and
applied all that.
--
Michael