Re: Errors creating partitioned tables from existing using (LIKE <table>) after renaming table constraints
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Stuart <sfbarbee@gmail.com>, pgsql-bugs@postgresql.org
Date: 2018-12-14T00:20:38Z
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
Commits
-
Make constraint rename issue relcache invalidation on target relation
- d5d86e2cd6b8 9.4.21 landed
- 5812be7b63cf 9.5.16 landed
- d79cd555da11 9.6.12 landed
- da13d90a5fba 10.7 landed
- 25b8094d33ac 11.2 landed
- b13fd344c5fc 12.0 landed