Re: VAC FULL/CLUSTER on system catalogs is prone to deadlock - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: VAC FULL/CLUSTER on system catalogs is prone to deadlock
Date
Msg-id 201002060055.o160tF629805@momjian.us
Whole thread Raw
In response to VAC FULL/CLUSTER on system catalogs is prone to deadlock  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 2. In VAC FULL and CLUSTER, tell index rebuild not to wait around for 
> INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples.  I believe that the
> price of this would be not re-verifying the integrity of unique indexes.
> Which is kind of annoying, but then again rechecking data consistency
> is not the purpose of these commands.  It would not be too unreasonable
> to tell people to use REINDEX if they suspect the validity of an index
> --- that takes a significantly weaker lock and wouldn't be nearly as
> big a problem to use on system catalogs.
> 
> 3. Try to ameliorate the problem by making sure it's the VACUUM FULL
> that fails, and not the other process, when there's a deadlock.
> 
> BTW, the reason we don't see this type of problem with the existing
> VAC FULL INPLACE logic is that it essentially silently adopts #2
> --- it suppresses uniqueness checks even when it's making new index
> insertions.
> 
> At the moment #2 is seeming like the most attractive alternative;
> both of the others look like research projects.  Comments?

Yea, #2.  No one has complained about this behavior in the past, as I
remember.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: VAC FULL/CLUSTER on system catalogs is prone to deadlock
Next
From: Tom Lane
Date:
Subject: Re: WIP patch for system-catalog vacuuming via a relation map