Wrong check in pg_visibility?

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Wrong check in pg_visibility?
Date: 2020-12-06 20:50:51
Message-ID: c0610352-8433-ab4b-986d-0e803c628efe@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-12-06 21:20:45 Re: Default role -> Predefined role
Previous Message Justin Pryzby 2020-12-06 18:02:48 pg_upgrade test for binary compatibility of core data types