Horton

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

Tender Wang <tndrwang@gmail.com>

View thread View on postgr.es
From: Tender Wang <tndrwang@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Junwang Zhao <zhjwpku@gmail.com>, Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Alexander Lakhin <exclusion@gmail.com>, Baehler Thomas SBB CFF FFS <thomas.baehler2@sbb.ch>, Guillaume Lelarge <guillaume@lelarge.info>
Date: 2024-08-23T02:44:19Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年8月23日周五 02:41写道：

> On 2024-Aug-22, Tender Wang wrote:
>
> > I apply the v14 patch on branch REL_14_STABLE. I run this thread issue
> and I
> > find below error.
> > [...]
> > ERROR:  cache lookup failed for constraint 16400
> >
> > I haven't look into details to find out where cause above error.
>
> Right, we try to drop the constraint twice.  We can dodge this by
> collecting all constraints to drop in the loop and process them in a
> single performMultipleDeletions, as in the attached v14-2.
>

Can we move the  CommandCounterIncrement() in
if (get_rel_relkind(fk->confrelid) == RELKIND_PARTITIONED_TABLE) block
to be close to performMultipleDeletions().

Others look good to me.

TBH I think it's a bit infuriating that we lose the constraint (which
> was explicitly declared) because of ATTACH/DETACH.


Agree.
Do you think it is friendly to users if we add hints that inform them the
constraint was dropped?

-- 
Tender Wang

Commits

  1. Fix some more bugs in foreign keys connecting partitioned tables

  2. Restructure foreign key handling code for ATTACH/DETACH

  3. Create foreign key triggers in partitioned tables too