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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Дата
Msg-id 20131209212431.GC2119@momjian.us
обсуждение исходный текст
Ответ на Bug in VACUUM reporting of "removed %d row versions" in 9.2+  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Список pgsql-hackers
Where are we on this?

---------------------------------------------------------------------------

On Fri, May 10, 2013 at 04:37:58PM +0100, Simon Riggs wrote:
> 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

> diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
> index 02f3cf3..f0d054a 100644
> --- a/src/backend/commands/vacuumlazy.c
> +++ b/src/backend/commands/vacuumlazy.c
> @@ -1052,15 +1052,15 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
>  static void
>  lazy_vacuum_heap(Relation onerel, LVRelStats *vacrelstats)
>  {
> -    int            tupindex;
> -    int            npages;
> +    int            tupindex = 0;
> +    int            npages = 0;
> +    int            ntupskipped = 0;
> +    int            npagesskipped = 0;
>      PGRUsage    ru0;
>      Buffer        vmbuffer = InvalidBuffer;
>  
>      pg_rusage_init(&ru0);
> -    npages = 0;
>  
> -    tupindex = 0;
>      while (tupindex < vacrelstats->num_dead_tuples)
>      {
>          BlockNumber tblk;
> @@ -1075,9 +1075,32 @@ lazy_vacuum_heap(Relation onerel, LVRelStats *vacrelstats)
>                                   vac_strategy);
>          if (!ConditionalLockBufferForCleanup(buf))
>          {
> -            ReleaseBuffer(buf);
> -            ++tupindex;
> -            continue;
> +            /*
> +             * If we can't get the lock, sleep, then try again just once.
> +             *
> +             * If we can't get the lock the second time, skip this block and
> +             * move onto the next one. This is possible because by now we
> +             * know the tuples are dead and all index pointers to them have been
> +             * removed, so it is safe to ignore them, even if not ideal.
> +             */
> +            VacuumCostBalance += VacuumCostLimit;
> +            vacuum_delay_point();
> +            if (!ConditionalLockBufferForCleanup(buf))
> +            {
> +                BlockNumber blkno = tblk;
> +
> +                ReleaseBuffer(buf);
> +                tupindex++;
> +                for (; tupindex < vacrelstats->num_dead_tuples; tupindex++)
> +                {
> +                    ntupskipped++;
> +                    tblk = ItemPointerGetBlockNumber(&vacrelstats->dead_tuples[tupindex]);
> +                    if (tblk != blkno)
> +                        break;
> +                }
> +                npagesskipped++;
> +                continue;
> +            }
>          }
>          tupindex = lazy_vacuum_page(onerel, tblk, buf, tupindex, vacrelstats,
>                                      &vmbuffer);
> @@ -1098,9 +1121,9 @@ lazy_vacuum_heap(Relation onerel, LVRelStats *vacrelstats)
>      }
>  
>      ereport(elevel,
> -            (errmsg("\"%s\": removed %d row versions in %d pages",
> +            (errmsg("\"%s\": removed %d row versions in %d pages (skipped %d row versions in %d pages)",
>                      RelationGetRelationName(onerel),
> -                    tupindex, npages),
> +                    tupindex - ntupskipped, npages, ntupskipped, npagesskipped),
>               errdetail("%s.",
>                         pg_rusage_show(&ru0))));
>  }

> 
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: ANALYZE sampling is too good