GIN VACUUM can corrupt internal posting tree pages

Opus 5 flagged a bug that can corrupt GIN indexes. All stable branches
are affected. It authored the attached patch, which adds a failing
isolation test demonstrating the problem. With assertions disabled,
the test shows a bitmap scan query that returns incorrect answers due
to this corruption (with asserts enabled, I get an
"Assert(ItemPointerIsValid(pointer))" failure instead).

ginVacuumPostingTreeLeaves() walks to the leftmost leaf of a posting
tree, takes the root under a share lock, drops it, and then re-takes
it in exclusive mode. Unlike similar code paths, it never re-checks
whether the page is still a leaf page after acquiring that exclusive
lock. It's therefore possible for VACUUM to treat an internal page as
a leaf page containing removable heap TIDs. I think that the specific
problem shown by the test case is a failure to visit all index pages
that might have TIDs that VACUUM is required to remove, to make it
safe to mark the line pointers LP_UNUSED in the heap. But the specific
scenario the test shows doesn't seem important; I imagine that this
oversight can have all kinds of unpleasant consequences.

--
Peter Geoghegan