Re: BUG #19070: issue with DETACH PARTITION CONCURRENTLY on ahash partition table
| От | ocean_li_996 |
|---|---|
| Тема | Re: BUG #19070: issue with DETACH PARTITION CONCURRENTLY on ahash partition table |
| Дата | |
| Msg-id | 5ca9d8f4.65cd.199d24b5fa6.Coremail.ocean_li_996@163.com обсуждение исходный текст |
| Ответ на | Re:Re: BUG #19070: issue with DETACH PARTITION CONCURRENTLY on ahash partition table ("songjinzhou" <tsinghualucky912@foxmail.com>) |
| Ответы |
Re: BUG #19070: issue with DETACH PARTITION CONCURRENTLY on ahashpartition table
|
| Список | pgsql-bugs |
Hello jinzhou,
Thanks for your opinion.
At 2025-10-11 10:00:54, "songjinzhou" <tsinghualucky912@foxmail.com> wrote:
> Hello hackers, Haiyang. I think the direct deletion of the DetachAddConstraintIfNeeded function in the patch above might not be a
> good idea. Will this create new problems?
>
> Of the two solutions Haiyang mentioned earlier, is the second one more appropriate? Should it be deleted after detaching? For
> example, somewhere in the DetachPartitionFinalize function?
AFAICS, the mainly difference between "Direct deletion of the DetachAddConstraintIfNeeded function" (thought 1)
and "Adding constraint first and removing it later" (thought 2) is the moment after the first transaction commit
of detach concurrently. In that moment, thought 1 will not add a constraint on detached partition and thought 2 will.
However, detached partition still have a partition constraint, which is functionally redundant with the newly added
constraint for a partition table. Regarding the partitioned table, once first transaction has committed, the partition
can be regarded as already detached from its parent. Therefore, I’m inclined to go with thought 1.
--
regards
Haiyang Li
В списке pgsql-bugs по дате отправления: