From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Stuart <sfbarbee(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Errors creating partitioned tables from existing using (LIKE <table>) after renaming table constraints |
Date: | 2018-12-14 00:20:38 |
Message-ID: | 20181214002038.GC2921@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Dec 13, 2018 at 06:03:35PM +0900, Amit Langote wrote:
> What's happening here is that when the ALTER TABLE RENAME CONSTRAINT is
> followed by CREATE TABLE (LIKE .. INCLUDING ALL) in the same session, the
> latter is referring to *stale* information about constraints of the source
> table. You said it works correctly after you drop and re-create the
> constraint, but that's only because ALTER TABLE DROP/ADD CONSTRAINT will
> correctly invalidate the cached information, so that subsequent CREATE
> TABLE sees the correct information from the updated cache. The way to fix
> it is to teach ALTER TABLE RENAME CONSTRAINT to reset the cached
> information.
This analysis looks right to me, and that's indeed a bug. And as far as
I can see this is reproducible down to 9.4. I cannot check your patch
in details today unfortunately, but I'll try to look at that in the next
couple of days and see if there are any surrounding issues.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-12-14 00:42:09 | Re: create partitioned table with (like table INCLUDING ALL ) fails with "insufficient columns in UNIQUE constraint definition" |
Previous Message | Anthony Sotolongo | 2018-12-13 23:54:50 | Re: problema version 10.6 |