aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvacuum.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2010-02-07 22:40:33 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2010-02-07 22:40:33 +0000
commit1ddc2703a936d03953657f43345460b9242bbed1 (patch)
treeb55bc003326fc288643f2cd7e30bf9c056a54ca3 /src/backend/access/gist/gistvacuum.c
parent1c05b0b4ea05fc73ea3612212c943cd459efa17d (diff)
downloadpostgresql-1ddc2703a936d03953657f43345460b9242bbed1.tar.gz
postgresql-1ddc2703a936d03953657f43345460b9242bbed1.zip
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.
Diffstat (limited to 'src/backend/access/gist/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions