Re: cache lookup failed for constraint when alter table referred by partition table
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-09-13T17:31:36Z
Lists: pgsql-hackers
Attachments
- v2-0001-fix-ALTER-TYPE.patch (text/plain)
On 2018-Sep-13, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> 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
Commits
-
Fix ALTER/TYPE on columns referenced by FKs in partitioned tables
- 6009bad91347 11.0 landed
- 20bef2c3110a 12.0 landed