Concurrent auto-analyze could be holding a snapshot, affecting the
removal of deleted row versions. Remove the deletion to avoid this
happening. Per buildfarm.
In passing, make the test independent of assumptions of physical row
order, just out of sheer paranoia.
starting permutation: modify vac stats
step modify:
insert into smalltbl select max(id)+1 from smalltbl;
- delete from smalltbl where id in (select min(id) from smalltbl);
step vac:
vacuum smalltbl;
relpages reltuples
-1 20
+1 21
starting permutation: modify open fetch1 vac close stats
step modify:
insert into smalltbl select max(id)+1 from smalltbl;
- delete from smalltbl where id in (select min(id) from smalltbl);
step open:
begin;
- declare c1 cursor for select * from smalltbl;
+ declare c1 cursor for select 1 as dummy from smalltbl;
step fetch1:
fetch next from c1;
-id
+dummy
-2
+1
step vac:
vacuum smalltbl;
starting permutation: modify vac stats
step modify:
insert into smalltbl select max(id)+1 from smalltbl;
- delete from smalltbl where id in (select min(id) from smalltbl);
step vac:
vacuum smalltbl;
relpages reltuples
-1 20
+1 21
# Test for vacuum's handling of reltuples when pages are skipped due
# to page pins. We absolutely need to avoid setting reltuples=0 in
# such cases, since that interferes badly with planning.
+#
+# Expected result in second permutation is 20 tuples rather than 21 as
+# for the others, because vacuum should leave the previous result
+# (from before the insert) in place.
setup {
create table smalltbl
session "worker"
step "open" {
begin;
- declare c1 cursor for select * from smalltbl;
+ declare c1 cursor for select 1 as dummy from smalltbl;
}
step "fetch1" {
fetch next from c1;
}
step "modify" {
insert into smalltbl select max(id)+1 from smalltbl;
- delete from smalltbl where id in (select min(id) from smalltbl);
}
permutation "modify" "vac" "stats"