Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
| От | Tender Wang |
|---|---|
| Тема | Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails |
| Дата | |
| Msg-id | CAHewXNmubkxLLCkS3D8tetbXDhCaYgdd-3UTLgE3C-HFfsHCRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails (Tender Wang <tndrwang@gmail.com>) |
| Список | 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
В списке pgsql-hackers по дате отправления: