On 2018/12/14 9:20, Michael Paquier wrote:
> 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.

Thank you for looking.  I noticed that the previously posted patch doesn't
apply as is to branches before 11, so here are the patches that apply to
9.4 to 10 branches.

Regards,
Amit