Re: cache lookup failed for constraint when alter table referred bypartition table

Поиск
Список
Период
Сортировка
Искать
От
Alvaro Herrera
Тема
Re: cache lookup failed for constraint when alter table referred bypartition table
Дата
Msg-id
20180913173136.4ktmsbbwxqk5hg2o@alvherre.pgsql
Ответ на
Список
Дерево обсуждения
cache lookup failed for constraint when alter table referred bypartition table Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>
Re: cache lookup failed for constraint when alter table referred bypartition table Justin Pryzby <pryzby@telsasoft.com>
Re: cache lookup failed for constraint when alter table referred bypartition table Alvaro Herrera <alvherre@2ndquadrant.com>
Re: cache lookup failed for constraint when alter table referred bypartition table Alvaro Herrera <alvherre@2ndquadrant.com>
Re: cache lookup failed for constraint when alter table referred bypartition table Alvaro Herrera <alvherre@2ndquadrant.com>
Re: cache lookup failed for constraint when alter table referred by partition table Tom Lane <tgl@sss.pgh.pa.us>
Re: cache lookup failed for constraint when alter table referred bypartition table Alvaro Herrera <alvherre@2ndquadrant.com>
Re: cache lookup failed for constraint when alter table referred bypartition table Alvaro Herrera <alvherre@2ndquadrant.com>
On 2018-Sep-13, Tom Lane wrote:

> Alvaro Herrera  writes:
> > That's the problem all right.  The solution is to drop all
> > index/constraint objects together in one performMultipleDeletions()
> > instead of performDeletion() one by one, as in the attached patch.
> 
> Looks reasonable as far as it goes.  Given that we no longer require
> any of this:
> 
> -	 * Now we can drop the existing constraints and indexes --- constraints
> -	 * first, since some of them might depend on the indexes.  In fact, we
> -	 * have to delete FOREIGN KEY constraints before UNIQUE constraints, but
> -	 * we already ordered the constraint list to ensure that would happen.
> 
> can we make any simplifications in earlier steps?  At the very least,
> look for comments related to this assumption.

Ah, I had looked, but not hard enough.  In this new version I removed
some code in ATExecAlterColumnType that's now irrelevant.  I tested this
by changing both lappend calls to lcons in that function; seems to
behave the same.  (Also added more constraints to the test case.)

Another thing I found I can change is to move the add_object_address()
calls to the other loops scanning the same lists, so that we don't have
to walk each the two lists twice.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления
От: Jonathan S. Katz
Дата:
От: Andres Freund
Дата:
Сообщение: Re: [patch] Support LLVM 7
FAQ