Thread: pgsql: Fix SPGiST vacuum algorithm to handle concurrent tuple motion pr

Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.

A leaf tuple that we need to delete could get moved as a consequence of an
insertion happening concurrently with the VACUUM scan.  If it moves from a
page past the current scan point to a page before, we'll miss it, which is
not acceptable.  Hence, when we see a leaf-page REDIRECT that could have
been made since our scan started, chase down the redirection pointer much
as if we were doing a normal index search, and be sure to vacuum every page
it leads to.  This fixes the issue because, if the tuple was on page N at
the instant we start our scan, we will surely find it as a consequence of
chasing the redirect from page N, no matter how much it moves around in
between.  Problem noted by Takashi Yamamoto.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/b4af1c25bbc636379efc5d2ffb9d420765705b8a

Modified Files
--------------
src/backend/access/spgist/README      |   21 +++
src/backend/access/spgist/spgvacuum.c |  231 +++++++++++++++++++++++++++++++--
2 files changed, 242 insertions(+), 10 deletions(-)