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

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. Another option might be to do find_all_inheritors() ahead of
time to grab all the necessary locks, but I didn't try to do that. I
also added an assertion in addFkRecurseReferenced to verify that we hold
that in all paths, and after this change it doesn't fire anymore with
the regression tests.

I have still not edited the commit message.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/