On Wed, Jun 23, 2021 at 6:35 AM houzj.f...@fujitsu.com <houzj.f...@fujitsu.com> wrote: > > On Tuesday, June 22, 2021 8:25 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jun 16, 2021 at 8:57 AM houzj.f...@fujitsu.com > > <houzj.f...@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 ? >
I was talking about adding/dropping CHECK or other constraints on partitioned tables via Alter Table. I think if attach/detach leads to change in constraints of child tables then either they should invalidate child rels to avoid problems in the existing sessions or if it is not doing due to a reason then probably it might not matter. I see that you have started a separate thread [1] to confirm the behavior of attach/detach partition and we might want to decide based on the conclusion of that thread. [1] - https://www.postgresql.org/message-id/OS3PR01MB5718DA1C4609A25186D1FBF194089%40OS3PR01MB5718.jpnprd01.prod.outlook.com -- With Regards, Amit Kapila.
