mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-25 15:07:20 +02:00
According to buildfarm member sungazer, the behavior of VACUUM can be
unstable in these tests even if we prevent autovacuum from running on
the tables in question, apparently because even a manual vacuum can
behave differently depending on whether anything else is running that
holds back the global xmin. So use a temporary table instead, which
as of commit a7212be8b9
enables
vacuuming using a more aggressive cutoff.
This approach can't be used for the regression test that involves a
materialized view, but that test doesn't run vacuum, so it shouldn't
be prone to this particular failure mode.
Analysis by Tom Lane. Patch by Ashutosh Sharma and me.
Discussion: http://postgr.es/m/665524.1599948007@sss.pgh.pa.us
89 lines
2.8 KiB
PL/PgSQL
89 lines
2.8 KiB
PL/PgSQL
create extension pg_surgery;
|
|
|
|
-- create a normal heap table and insert some rows.
|
|
-- use a temp table so that vacuum behavior doesn't depend on global xmin
|
|
create temp table htab (a int);
|
|
insert into htab values (100), (200), (300), (400), (500);
|
|
|
|
-- test empty TID array
|
|
select heap_force_freeze('htab'::regclass, ARRAY[]::tid[]);
|
|
|
|
-- nothing should be frozen yet
|
|
select * from htab where xmin = 2;
|
|
|
|
-- freeze forcibly
|
|
select heap_force_freeze('htab'::regclass, ARRAY['(0, 4)']::tid[]);
|
|
|
|
-- now we should have one frozen tuple
|
|
select ctid, xmax from htab where xmin = 2;
|
|
|
|
-- kill forcibly
|
|
select heap_force_kill('htab'::regclass, ARRAY['(0, 4)']::tid[]);
|
|
|
|
-- should be gone now
|
|
select * from htab where ctid = '(0, 4)';
|
|
|
|
-- should now be skipped because it's already dead
|
|
select heap_force_kill('htab'::regclass, ARRAY['(0, 4)']::tid[]);
|
|
select heap_force_freeze('htab'::regclass, ARRAY['(0, 4)']::tid[]);
|
|
|
|
-- freeze two TIDs at once while skipping an out-of-range block number
|
|
select heap_force_freeze('htab'::regclass,
|
|
ARRAY['(0, 1)', '(0, 3)', '(1, 1)']::tid[]);
|
|
|
|
-- we should now have two frozen tuples
|
|
select ctid, xmax from htab where xmin = 2;
|
|
|
|
-- out-of-range TIDs should be skipped
|
|
select heap_force_freeze('htab'::regclass, ARRAY['(0, 0)', '(0, 6)']::tid[]);
|
|
|
|
-- set up a new table with a redirected line pointer
|
|
-- use a temp table so that vacuum behavior doesn't depend on global xmin
|
|
create temp table htab2(a int);
|
|
insert into htab2 values (100);
|
|
update htab2 set a = 200;
|
|
vacuum htab2;
|
|
|
|
-- redirected TIDs should be skipped
|
|
select heap_force_kill('htab2'::regclass, ARRAY['(0, 1)']::tid[]);
|
|
|
|
-- now create an unused line pointer
|
|
select ctid from htab2;
|
|
update htab2 set a = 300;
|
|
select ctid from htab2;
|
|
vacuum freeze htab2;
|
|
|
|
-- unused TIDs should be skipped
|
|
select heap_force_kill('htab2'::regclass, ARRAY['(0, 2)']::tid[]);
|
|
|
|
-- multidimensional TID array should be rejected
|
|
select heap_force_kill('htab2'::regclass, ARRAY[['(0, 2)']]::tid[]);
|
|
|
|
-- TID array with nulls should be rejected
|
|
select heap_force_kill('htab2'::regclass, ARRAY[NULL]::tid[]);
|
|
|
|
-- but we should be able to kill the one tuple we have
|
|
select heap_force_kill('htab2'::regclass, ARRAY['(0, 3)']::tid[]);
|
|
|
|
-- materialized view.
|
|
-- note that we don't commit the transaction, so autovacuum can't interfere.
|
|
begin;
|
|
create materialized view mvw as select a from generate_series(1, 3) a;
|
|
|
|
select * from mvw where xmin = 2;
|
|
select heap_force_freeze('mvw'::regclass, ARRAY['(0, 3)']::tid[]);
|
|
select * from mvw where xmin = 2;
|
|
|
|
select heap_force_kill('mvw'::regclass, ARRAY['(0, 3)']::tid[]);
|
|
select * from mvw where ctid = '(0, 3)';
|
|
rollback;
|
|
|
|
-- check that it fails on an unsupported relkind
|
|
create view vw as select 1;
|
|
select heap_force_kill('vw'::regclass, ARRAY['(0, 1)']::tid[]);
|
|
select heap_force_freeze('vw'::regclass, ARRAY['(0, 1)']::tid[]);
|
|
|
|
-- cleanup.
|
|
drop view vw;
|
|
drop extension pg_surgery;
|