The previous code was only skipping a tuple with no data if the page was leftmost. That was too restrictive. Any non-leaf page might have an empty tuple in the first data key location (1 or 2, depending on whether the page is rightmost), so that check is expanded a bit.
Postgres allows this situation to occur, and simply assumes that the trailing attributes are NULL. This change makes pg_check only examine up to the number of attributes actually in the tuple. I don't know how to create this situation in a test, I've only seen it in production data so far.
…EX_VAR_MASK map). Now it's checked how much data are there using (IndexTupleSize-IndexInfoFindDataOffset) and if the difference is 0, the item length check is skipped.
tuple end' messages. It seems there's a INDEX_VAR_MASK flag in each tuple, and when this is 'false' then there are no data (but this needs verification and maybe a review).
… Per the comments and README, they are not real tuples, but the the check to detect them was not accounting high-keys correctly. Also, be consistent about printing the offset number as a 1-based number in debug/warning messages.
By default, ACCESS SHARE lock is acquired. When cross-checking the table and indexes, a more restrictive SHARE ROW EXCLUSIVE lock needs to be acquired (preventing modifications of the table and indexes),
when the bitmap format is set to none).
for enabling debugging info and the other one (pg_check.bitmap_format) to set bitmap format (none, binary, hex or base64).
… and btree indexes (missing items etc.).
…/), added META.json.
…r as our checks are concerned.
…se we don't know how to check them.