Re: VAC FULL/CLUSTER on system catalogs is prone to deadlock
От | Bruce Momjian |
---|---|
Тема | Re: VAC FULL/CLUSTER on system catalogs is prone to deadlock |
Дата | |
Msg-id | 201002060055.o160tF629805@momjian.us обсуждение исходный текст |
Ответ на | VAC FULL/CLUSTER on system catalogs is prone to deadlock (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: