Re: pgstattuple "unexpected zero page" for gist and hash indexes

On Tue, Sep 30, 2025 at 05:31:46PM +0530, Dilip Kumar wrote:
> My primary concern is the handling of non-new pages where the page's
> special size does not match GISTPageOpaqueData (same for
> pgstat_hash_page()). I mean isn't that corruption and this should be
> reported.  OTOH, pgstat_btree_page() is also not reporting it, in fact
> it is assuming that if the page is not new then it can safely read the
> page opaque data without validating the size.  My additional goal with
> this patch is to standardize the validation logic across all three
> functions to prevent these inconsistencies in the future.

pgstattuple's job is to report tuple-level statistics.  I don't really
think that we need to make it more complicated or smarter to detect
corruption cases, because we have other tools that are designed for
that, like amcheck.  True that amcheck does not have support for gist
and hash as checks for index AMs, but it's something that could be
sorted out on its own as a new feature.

From this perspective, v2 seems kind of fine based on its simplicity
and because it makes pgstattuple do a better job in terms of
statistics numbers reported.  I think that I would just remove the "or
corrupted" in the extra comment, though.
--
Michael