Re: [SP-]GiST IOS visibility bug (was: Why doens't GiST require super-exclusive lock)

Hi Paul,

I tested the v4 patch series on REL_19_STABLE.

Here are my test results:

- v4-0001 through v4-0004 applied cleanly.
- PostgreSQL built successfully.
- 'make check' passed with 239/239 tests.
- The isolation test suite passed with 135/135 tests with the complete
v4 series.
- The new GiST and SP-GiST IOS/VACUUM tests passed for both sorted and
unsorted scans.
- I also tested the new v4-0004 regression tests on unpatched
REL_19_STABLE. In that case, 2 of 135 isolation tests failed:
- 'index-only-scan-gist-vacuum'
- 'index-only-scan-spgist-vacuum'
- Without the fixes, both tests returned the 9 rows that had been
deleted before VACUUM, instead of the expected 0 rows.
- With the complete v4 series applied, both tests passed and returned
the expected 0 rows after VACUUM.
- I also checked the SP-GiST visibility check and confirmed that it
uses 'leafTuple->heapPtr' for the visibility check.

And one observation on my review is that the isolation tests force
enable_indexonlyscan = true and disable bitmap scans, but they do not
explicitly verify the selected plan with EXPLAIN.

Overall, the v4 series passed my testing, and the new regression tests
correctly exposed the issue on the unpatched code.

Regards,
Solai