Commit 34a947ca authored by Robert Haas's avatar Robert Haas

New contrib module, pg_surgery, with heap surgery functions.

Sometimes it happens that the visibility information for a tuple
becomes corrupted, either due to bugs in the database software or
external factors. Provide a function heap_force_kill() that can
be used to truncate such dead tuples to dead line pointers, and
a function heap_force_freeze() that can be used to overwrite the
visibility information in such a way that the tuple becomes
all-visible.

These functions are unsafe, in that you can easily use them to
corrupt a database that was not previously corrupted, and you can
use them to further corrupt an already-corrupted database or to
destroy data. The documentation accordingly cautions against
casual use. However, in some cases they permit recovery of data
that would otherwise be very difficult to recover, or to allow a
system to continue to function when it would otherwise be difficult
to do so.

Because we may want to add other functions for performing other
kinds of surgery in the future, the new contrib module is called
pg_surgery rather than something specific to these functions. I
proposed back-patching this so that it could be more easily used
by people running existing releases who are facing these kinds of
problems, but that proposal did not attract enough support, so
no back-patch for now.

Ashutosh Sharma, reviewed and tested by Andrey M. Borodin,
M. Beena Emerson, Masahiko Sawada, Rajkumar Raghuwanshi,
Asim Praveen, and Mark Dilger, and somewhat revised by me.

Discussion: http://postgr.es/m/CA+TgmoZW1fsU-QUNCRUQMGUygBDPVeOTLCqRdQZch=EYZnctSA@mail.gmail.com
parent c02767d2
...@@ -34,6 +34,7 @@ SUBDIRS = \ ...@@ -34,6 +34,7 @@ SUBDIRS = \
pg_prewarm \ pg_prewarm \
pg_standby \ pg_standby \
pg_stat_statements \ pg_stat_statements \
pg_surgery \
pg_trgm \ pg_trgm \
pgcrypto \ pgcrypto \
pgrowlocks \ pgrowlocks \
......
# Generated subdirectories
/log/
/results/
/tmp_check/
# contrib/pg_surgery/Makefile
MODULE_big = pg_surgery
OBJS = \
$(WIN32RES) \
heap_surgery.o
EXTENSION = pg_surgery
DATA = pg_surgery--1.0.sql
PGFILEDESC = "pg_surgery - perform surgery on a damaged relation"
REGRESS = heap_surgery
ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
else
subdir = contrib/pg_surgery
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
create extension pg_surgery;
-- create a normal heap table and insert some rows.
-- note that we don't commit the transaction, so autovacuum can't interfere.
begin;
create 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[]);
heap_force_freeze
-------------------
(1 row)
-- nothing should be frozen yet
select * from htab where xmin = 2;
a
---
(0 rows)
-- freeze forcibly
select heap_force_freeze('htab'::regclass, ARRAY['(0, 4)']::tid[]);
heap_force_freeze
-------------------
(1 row)
-- now we should have one frozen tuple
select ctid, xmax from htab where xmin = 2;
ctid | xmax
-------+------
(0,4) | 0
(1 row)
-- kill forcibly
select heap_force_kill('htab'::regclass, ARRAY['(0, 4)']::tid[]);
heap_force_kill
-----------------
(1 row)
-- should be gone now
select * from htab where ctid = '(0, 4)';
a
---
(0 rows)
-- should now be skipped because it's already dead
select heap_force_kill('htab'::regclass, ARRAY['(0, 4)']::tid[]);
NOTICE: skipping tid (0, 4) for relation "htab" because it is marked dead
heap_force_kill
-----------------
(1 row)
select heap_force_freeze('htab'::regclass, ARRAY['(0, 4)']::tid[]);
NOTICE: skipping tid (0, 4) for relation "htab" because it is marked dead
heap_force_freeze
-------------------
(1 row)
-- 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[]);
NOTICE: skipping block 1 for relation "htab" because the block number is out of range
heap_force_freeze
-------------------
(1 row)
-- we should now have two frozen tuples
select ctid, xmax from htab where xmin = 2;
ctid | xmax
-------+------
(0,1) | 0
(0,3) | 0
(2 rows)
-- out-of-range TIDs should be skipped
select heap_force_freeze('htab'::regclass, ARRAY['(0, 0)', '(0, 6)']::tid[]);
NOTICE: skipping tid (0, 0) for relation "htab" because the item number is out of range
NOTICE: skipping tid (0, 6) for relation "htab" because the item number is out of range
heap_force_freeze
-------------------
(1 row)
rollback;
-- set up a new table with a redirected line pointer
create table htab2(a int) with (autovacuum_enabled = off);
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[]);
NOTICE: skipping tid (0, 1) for relation "htab2" because it redirects to item 2
heap_force_kill
-----------------
(1 row)
-- now create an unused line pointer
select ctid from htab2;
ctid
-------
(0,2)
(1 row)
update htab2 set a = 300;
select ctid from htab2;
ctid
-------
(0,3)
(1 row)
vacuum freeze htab2;
-- unused TIDs should be skipped
select heap_force_kill('htab2'::regclass, ARRAY['(0, 2)']::tid[]);
NOTICE: skipping tid (0, 2) for relation "htab2" because it is marked unused
heap_force_kill
-----------------
(1 row)
-- multidimensional TID array should be rejected
select heap_force_kill('htab2'::regclass, ARRAY[['(0, 2)']]::tid[]);
ERROR: argument must be empty or one-dimensional array
-- TID array with nulls should be rejected
select heap_force_kill('htab2'::regclass, ARRAY[NULL]::tid[]);
ERROR: array must not contain nulls
-- but we should be able to kill the one tuple we have
select heap_force_kill('htab2'::regclass, ARRAY['(0, 3)']::tid[]);
heap_force_kill
-----------------
(1 row)
-- 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;
a
---
(0 rows)
select heap_force_freeze('mvw'::regclass, ARRAY['(0, 3)']::tid[]);
heap_force_freeze
-------------------
(1 row)
select * from mvw where xmin = 2;
a
---
3
(1 row)
select heap_force_kill('mvw'::regclass, ARRAY['(0, 3)']::tid[]);
heap_force_kill
-----------------
(1 row)
select * from mvw where ctid = '(0, 3)';
a
---
(0 rows)
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[]);
ERROR: "vw" is not a table, materialized view, or TOAST table
select heap_force_freeze('vw'::regclass, ARRAY['(0, 1)']::tid[]);
ERROR: "vw" is not a table, materialized view, or TOAST table
-- cleanup.
drop table htab2;
drop view vw;
drop extension pg_surgery;
This diff is collapsed.
/* contrib/pg_surgery/pg_surgery--1.0.sql */
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION pg_surgery" to load this file. \quit
CREATE FUNCTION heap_force_kill(reloid regclass, tids tid[])
RETURNS VOID
AS 'MODULE_PATHNAME', 'heap_force_kill'
LANGUAGE C STRICT;
REVOKE EXECUTE ON FUNCTION heap_force_kill(regclass, tid[]) FROM PUBLIC;
CREATE FUNCTION heap_force_freeze(reloid regclass, tids tid[])
RETURNS VOID
AS 'MODULE_PATHNAME', 'heap_force_freeze'
LANGUAGE C STRICT;
REVOKE EXECUTE ON FUNCTION heap_force_freeze(regclass, tid[]) FROM PUBLIC;
\ No newline at end of file
# pg_surgery extension
comment = 'extension to perform surgery on a damaged relation'
default_version = '1.0'
module_pathname = '$libdir/pg_surgery'
relocatable = true
create extension pg_surgery;
-- create a normal heap table and insert some rows.
-- note that we don't commit the transaction, so autovacuum can't interfere.
begin;
create 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[]);
rollback;
-- set up a new table with a redirected line pointer
create table htab2(a int) with (autovacuum_enabled = off);
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 table htab2;
drop view vw;
drop extension pg_surgery;
...@@ -125,6 +125,7 @@ CREATE EXTENSION <replaceable>module_name</replaceable>; ...@@ -125,6 +125,7 @@ CREATE EXTENSION <replaceable>module_name</replaceable>;
&pgrowlocks; &pgrowlocks;
&pgstatstatements; &pgstatstatements;
&pgstattuple; &pgstattuple;
&pgsurgery;
&pgtrgm; &pgtrgm;
&pgvisibility; &pgvisibility;
&postgres-fdw; &postgres-fdw;
......
...@@ -139,6 +139,7 @@ ...@@ -139,6 +139,7 @@
<!ENTITY pgstandby SYSTEM "pgstandby.sgml"> <!ENTITY pgstandby SYSTEM "pgstandby.sgml">
<!ENTITY pgstatstatements SYSTEM "pgstatstatements.sgml"> <!ENTITY pgstatstatements SYSTEM "pgstatstatements.sgml">
<!ENTITY pgstattuple SYSTEM "pgstattuple.sgml"> <!ENTITY pgstattuple SYSTEM "pgstattuple.sgml">
<!ENTITY pgsurgery SYSTEM "pgsurgery.sgml">
<!ENTITY pgtrgm SYSTEM "pgtrgm.sgml"> <!ENTITY pgtrgm SYSTEM "pgtrgm.sgml">
<!ENTITY pgvisibility SYSTEM "pgvisibility.sgml"> <!ENTITY pgvisibility SYSTEM "pgvisibility.sgml">
<!ENTITY postgres-fdw SYSTEM "postgres-fdw.sgml"> <!ENTITY postgres-fdw SYSTEM "postgres-fdw.sgml">
......
<!-- doc/src/sgml/pgsurgery.sgml -->
<sect1 id="pgsurgery" xreflabel="pg_surgery">
<title>pg_surgery</title>
<indexterm zone="pgsurgery">
<primary>pg_surgery</primary>
</indexterm>
<para>
The <filename>pg_surgery</filename> module provides various functions to
perform surgery on a damaged relation. These functions are unsafe by design
and using them may corrupt (or further corrupt) your database. For example,
these functions can easily be used to make a table inconsistent with its
own indexes, to cause <literal>UNIQUE</literal> or
<literal>FOREIGN KEY</literal> constraint violations, or even to make
tuples visible which, when read, will cause a database server crash.
They should be used with great caution and only as a last resort.
</para>
<sect2>
<title>Functions</title>
<variablelist>
<varlistentry>
<term>
<function>heap_force_kill(regclass, tid[]) returns void</function>
</term>
<listitem>
<para>
<function>heap_force_kill</function> marks <quote>used</quote> line
pointers as <quote>dead</quote> without examining the tuples. The
intended use of this function is to forcibly remove tuples that are not
otherwise accessible. For example:
<programlisting>
test=&gt; select * from t1 where ctid = '(0, 1)';
ERROR: could not access status of transaction 4007513275
DETAIL: Could not open file "pg_xact/0EED": No such file or directory.
test=# select heap_force_kill('t1'::regclass, ARRAY['(0, 1)']::tid[]);
heap_force_kill
-----------------
(1 row)
test=# select * from t1 where ctid = '(0, 1)';
(0 rows)
</programlisting>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<function>heap_force_freeze(regclass, tid[]) returns void</function>
</term>
<listitem>
<para>
<function>heap_force_freeze</function> marks tuples as frozen without
examining the tuple data. The intended use of this function is to
make accessible tuples which are inaccessible due to corrupted
visibility information, or which prevent the table from being
successfully vacuumed due to corrupted visibility information.
For example:
<programlisting>
test=&gt; vacuum t1;
ERROR: found xmin 507 from before relfrozenxid 515
CONTEXT: while scanning block 0 of relation "public.t1"
test=# select ctid from t1 where xmin = 507;
ctid
-------
(0,3)
(1 row)
test=# select heap_force_freeze('t1'::regclass, ARRAY['(0, 3)']::tid[]);
heap_force_freeze
-------------------
(1 row)
test=# select ctid from t1 where xmin = 2;
ctid
-------
(0,3)
(1 row)
</programlisting>
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>Authors</title>
<para>
Ashutosh Sharma <email>ashu.coek88@gmail.com</email>
</para>
</sect2>
</sect1>
...@@ -3578,3 +3578,4 @@ yyscan_t ...@@ -3578,3 +3578,4 @@ yyscan_t
z_stream z_stream
z_streamp z_streamp
zic_t zic_t
HeapTupleForceOption
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment