RE: [bug?] Missed parallel safety checks, and wrong parallel safety
От | houzj.fnst@fujitsu.com |
---|---|
Тема | RE: [bug?] Missed parallel safety checks, and wrong parallel safety |
Дата | |
Msg-id | OS3PR01MB57180280597BC37FCBEFE38594089@OS3PR01MB5718.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: [bug?] Missed parallel safety checks, and wrong parallel safety (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [bug?] Missed parallel safety checks, and wrong parallel safety
|
Список | pgsql-hackers |
On Tuesday, June 22, 2021 8:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > On Wed, Jun 16, 2021 at 8:57 AM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: > > > > I think the check of partition could be even more complicated if we > > need to check the parallel safety of partition key expression. If user > > directly insert into a partition, then we need invoke > > ExecPartitionCheck which will execute all it's parent's and > > grandparent's partition key expressions. It means if we change a > > parent table's partition key expression(by 1) change function in expr > > or 2) attach the parent table as partition of another parent table), then we > need to invalidate all its child's relcache. > > > > I think we already invalidate the child entries when we add/drop constraints on > a parent table. See ATAddCheckConstraint, ATExecDropConstraint. If I am not > missing anything then this case shouldn't be a problem. Do you have > something else in mind? Currently, attach/detach a partition doesn't invalidate the child entries recursively, except when detach a partition concurrently which will add a constraint to all the child. Do you mean we can add the logic about invalidating the child entries recursively when attach/detach a partition ? Best regards, houzj
В списке pgsql-hackers по дате отправления: