Bug in VACUUM reporting of "removed %d row versions" in 9.2+ - Mailing list pgsql-hackers

From Simon Riggs
Subject Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Date
Msg-id CA+U5nMJ+kRY+WAFRqN9m=wRn0-FfNuF+XJV=QqUtiEi1y29K5Q@mail.gmail.com
Whole thread Raw
Responses Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+  (Robert Haas <robertmhaas@gmail.com>)
Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Commit d0dcb315db0043f10073a9a244cea138e9e60edd and previous
introduced a bug into the reporting of removed row versions. ('Twas
myself et al, before you ask).

In those commits, lazy_vacuum_heap() skipped pinned blocks, but then
failed to report that accurately, claiming that the tuples were
actually removed when they were not. That bug has masked the effect of
the page skipping behaviour.

Bug is in 9.2 and HEAD.

Attached patch corrects that, with logic to move to the next block
rather than re-try the lock in a tight loop once per tuple, which was
mostly ineffective.

Attached patch also changes the algorithm slightly to retry a skipped
block by sleeping and then retrying the block, following observation
of the effects of the current skipping algorithm once skipped rows are
correctly reported.

It also adds a comment which explains the skipping behaviour.

Viewpoints?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: [PATCH] Make "psql -1 < file.sql" work as with "-f"
Next
From: Simon Riggs
Date:
Subject: Re: Concurrent HOT Update interference