Bug in VACUUM reporting of "removed %d row versions" in 9.2+

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Дата
Msg-id CA+U5nMJ+kRY+WAFRqN9m=wRn0-FfNuF+XJV=QqUtiEi1y29K5Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: [PATCH] Make "psql -1 < file.sql" work as with "-f"
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Concurrent HOT Update interference