From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: VAC FULL/CLUSTER on system catalogs is prone to deadlock |
Date: | 2010-02-06 00:55:15 |
Message-ID: | 201002060055.o160tF629805@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2010-02-06 01:25:33 | Hot Standby and DROP DATABASE |
Previous Message | Tom Lane | 2010-02-06 00:55:06 | Re: WIP patch for system-catalog vacuuming via a relation map |