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