Wrong check in pg_visibility?

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Wrong check in pg_visibility?
Дата
Msg-id c0610352-8433-ab4b-986d-0e803c628efe@postgrespro.ru
обсуждение исходный текст
Ответы Re: Wrong check in pg_visibility?  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
Hi hackers!

Due to the error in PG-ProEE we have added the following test to 
pg_visibility:

create table vacuum_test as select 42 i;
vacuum vacuum_test;
select count(*) > 0 from pg_check_visible('vacuum_test');
drop table vacuum_test;

Sometime (very rarely) this test failed: pg_visibility reports 
"corrupted" tuples.
The same error can be reproduced not only with PG-Pro but also with 
vanilla REL_11_STABLE, REL_12_STABLE and REL_13_STABLE.
It is not reproduced with master after Andres snapshot optimization - 
commit dc7420c2.

It is not so easy to reproduce this error: it is necessary to repeat 
this tests many times.
Probability increased with more aggressive autovacuum settings.
But even with such settings and thousands of iterations I was not able 
to reproduce this error at my notebook - only at virtual machine.

The error is reported here:

             /*
              * If we're checking whether the page is all-visible, we expect
              * the tuple to be all-visible.
              */
             if (check_visible &&
                 !tuple_all_visible(&tuple, OldestXmin, buffer))
             {
                 TransactionId RecomputedOldestXmin;

                 /*
                  * Time has passed since we computed OldestXmin, so it's
                  * possible that this tuple is all-visible in reality even
                  * though it doesn't appear so based on our
                  * previously-computed value.  Let's compute a new 
value so we
                  * can be certain whether there is a problem.
                  *
                  * From a concurrency point of view, it sort of sucks to
                  * retake ProcArrayLock here while we're holding the buffer
                  * exclusively locked, but it should be safe against
                  * deadlocks, because surely GetOldestXmin() should 
never take
                  * a buffer lock. And this shouldn't happen often, so it's
                  * worth being careful so as to avoid false positives.
                  */
                 RecomputedOldestXmin = GetOldestXmin(NULL, 
PROCARRAY_FLAGS_VACUUM);

                 if (!TransactionIdPrecedes(OldestXmin, 
RecomputedOldestXmin))
                     record_corrupt_item(items, &tuple.t_self);


I debugger I have checked that OldestXmin = RecomputedOldestXmin = 
tuple.t_data->xmin
I wonder if this check in pg_visibility is really correct and it can not 
happen that OldestXmin=tuple.t_data->xmin?
Please notice that tuple_all_visible returns false if 
!TransactionIdPrecedes(xmin, OldestXmin)

Thanks in advance,
Konstantin





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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: pg_upgrade test for binary compatibility of core data types
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Default role -> Predefined role