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
signature.asc
Description: PGP signature
