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(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
