Re: [BUGS] BUG #14057: vacuum setting reltuples=0 for tables with >0 tuples - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: [BUGS] BUG #14057: vacuum setting reltuples=0 for tables with >0 tuples
Date
Msg-id 874lytj697.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: [BUGS] BUG #14057: vacuum setting reltuples=0 for tables with >0tuples  (Andres Freund <andres@anarazel.de>)
Responses Re: [BUGS] BUG #14057: vacuum setting reltuples=0 for tables with >0tuples  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
>>>>> "Andres" == Andres Freund <andres@anarazel.de> writes:

 >> I've reproduced the bug on all of them, and confirmed that this
 >> fixes it on all of them.  Is it worth also including the isolation
 >> tester script in the changes?

 Andres> Hm, I haven't seen the isolationtester test (it's not in this
 Andres> thread, right?) - how fragile and how slow is it?

Oh, sorry, forgot to include that. There are two versions of the test,
because the error is slightly harder to reproduce in older branches;
this one works in 9.6 and master:

setup {
    create table smalltbl
      as select i as id,
                'foo '||i as val
           from generate_series(1,20) i;
}
setup {
    vacuum analyze smalltbl;               
}
teardown {
    drop table smalltbl;
}

session "worker"
step "open" { BEGIN; DECLARE c1 CURSOR FOR select * from smalltbl; }
step "fetch1" { FETCH NEXT FROM c1; }
step "close" { COMMIT; }
step "stats" { select relpages, reltuples from pg_class where oid='smalltbl'::regclass; }

session "vacuumer"
step "vac" { VACUUM smalltbl; }
step "modify" {
    insert into smalltbl
      select max(id)+1, 'foo '||(max(id) + 1) from smalltbl;
    delete from smalltbl
      where id in (select min(id) from smalltbl);
}

permutation "modify" "vac" "stats"
permutation "modify" "open" "fetch1" "vac" "close" "stats"
permutation "modify" "vac" "stats"

The first and last permutations return relpages=1 reltuples=20 as
expected, but the middle one returns relpages=1 reltuples=0 when the bug
is present, due to the worker thread's cursor holding a pin on the page.

9.5 and before need a slightly more complex setup that juggles the
values of vacuum_freeze_table_age and relfrozenxid in order to get the
right code path in vacuum.

They don't seem to be fragile at all - there are no timing issues and
the results always seem to be consistent. There's no locking and runtime
is basically just how long to create/drop the table and do 3 rounds of
updates/vacuums on it.

-- 
Andrew (irc:RhodiumToad)


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

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUGS] ON CONFLICT with constraint name doesn't work
Next
From: Andres Freund
Date:
Subject: Re: [BUGS] BUG #14057: vacuum setting reltuples=0 for tables with >0tuples