Re: create partition table caused server crashed with self-referencing foreign key

Amul Sul <sulamul@gmail.com>

From: amul sul <sulamul@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-04-22T09:29:38Z
Lists: pgsql-hackers

Attachments

On Wed, Apr 22, 2020 at 2:27 PM David Rowley <dgrowleyml@gmail.com> wrote:

> On Wed, 22 Apr 2020 at 20:11, amul sul <sulamul@gmail.com> wrote:
> >
> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi <
> rajkumar.raghuwanshi@enterprisedb.com> wrote:
> >> #2  0x0000000000acd16a in ExceptionalCondition (conditionName=0xc32310
> "numfks == attmap->maplen", errorType=0xc2ea23 "FailedAssertion",
> fileName=0xc2f0bf "tablecmds.c", lineNumber=9046) at assert.c:67
> >
> >
> > Looks like this assertion is incorrect, I guess it should have check
> > numfks <= attmap->maplen instead.
>
> Even that seems like a very strange thing to Assert. Basically it's
> saying, make sure the number of columns in the foreign key constraint
> is less than or equal to the number of attributes in parentRel.
>
> It's true we do disallow duplicate column names in the foreign key
> constraint (at least since 9da867537), but why do we want an Assert to
> say that?  I don't see anything about that code that would break if we
> did happen to allow duplicate columns in the foreign key.  I'd say the
> Assert should just be removed completely.
>

Understood and agree with you.

Attached patch removes this assertion and does a slight tweak to regression
test
to generate case where numfks != attmap->maplen, IMO, we should have this
even if there is nothing that checks it. Thoughts?

Regards,
Amul

Commits

  1. Remove bogus Assert in foreign key cloning code