Skip site navigation (1) Skip section navigation (2)

pgsql: Work around deadlock problems with VACUUM FULL/CLUSTER on system

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 (view raw or flat)
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)

pgsql-committers by date

Next:From: Tom LaneDate: 2010-02-07 22:52:02
Subject: Re: pgsql: Create a "relation mapping" infrastructure to support changing
Previous:From: Simon RiggsDate: 2010-02-07 22:29:17
Subject: Re: pgsql: Create a "relation mapping" infrastructure to support changing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group