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: Alexander Lakhin <exclusion@gmail.com>, Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Guillaume Lelarge <guillaume@lelarge.info>
Date: 2024-10-28T11:42:54Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年10月28日周一 17:16写道：

> On 2024-Oct-27, Tender Wang wrote:
>
> > BTW, while reviewing the v2 patch, I found the parentConTup in
> > foreach(cell, fks) block
> > didn't need it anymore. We can remove the related codes.
>
> True.  Done so in this v3.
>
> I noticed another problem here: we're grabbing the wrong lock type on
> the referenced rel (AccessShareLock) during detach.  (What's more: we
> release it afterwards, which is the wrong thing to do.  We need to keep
> such locks until end of transaction).  I didn't try to construct a case
> where this would be a problem, but if I change AccessShare to NoLock,
> the assertion that says we don't hold _any_ lock on that relation fires,
> which means that we're not taking any locks on those rels before this
> point.  So this lock strength choice is definitely wrong.  I changed it
> to ShareRowExclusive, which is what we're suppose to use when adding a
> trigger.


In CloneFKReferencing(), the constrForm->confrelid uses the same lock type.
I think you're right. I don't find any other problem.


-- 
Thanks,
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