From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Work around deadlock problems with VACUUM FULL/CLUSTER on system |
Date: | 2010-02-07 22:40:33 |
Message-ID: | 20100207224033.8E5087541B9@cvs.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
Work around deadlock problems with VACUUM FULL/CLUSTER on system catalogs,
as per my recent proposal.
First, teach IndexBuildHeapScan to not wait for INSERT_IN_PROGRESS or
DELETE_IN_PROGRESS tuples to commit unless the index build is checking
uniqueness/exclusion constraints. If it isn't, there's no harm in just
indexing the in-doubt tuple.
Second, modify VACUUM FULL/CLUSTER to suppress reverifying
uniqueness/exclusion constraint properties while rebuilding indexes of
the target relation. This is reasonable because these commands aren't
meant to deal with corrupted-data situations. Constraint properties
will still be rechecked when an index is rebuilt by a REINDEX command.
This gets us out of the problem that new-style VACUUM FULL would often
wait for other transactions while holding exclusive lock on a system
catalog, leading to probable deadlock because those other transactions
need to look at the catalogs too. Although the real ultimate cause of
the problem is a debatable choice to release locks early after modifying
system catalogs, changing that choice would require pretty serious
analysis and is not something to be undertaken lightly or on a tight
schedule. The present patch fixes the problem in a fairly reasonable
way and should also improve the speed of VACUUM FULL/CLUSTER a little bit.
Modified Files:
--------------
pgsql/src/backend/catalog:
index.c (r1.333 -> r1.334)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/index.c?r1=1.333&r2=1.334)
pgsql/src/backend/commands:
cluster.c (r1.198 -> r1.199)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/cluster.c?r1=1.198&r2=1.199)
indexcmds.c (r1.191 -> r1.192)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/indexcmds.c?r1=1.191&r2=1.192)
pgsql/src/include/catalog:
index.h (r1.82 -> r1.83)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/index.h?r1=1.82&r2=1.83)
pgsql/src/test/regress:
parallel_schedule (r1.59 -> r1.60)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/parallel_schedule?r1=1.59&r2=1.60)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-07 22:52:02 | Re: pgsql: Create a "relation mapping" infrastructure to support changing |
Previous Message | Simon Riggs | 2010-02-07 22:29:17 | Re: pgsql: Create a "relation mapping" infrastructure to support changing |