From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Greg Nancarrow <gregn4422(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel INSERT (INTO ... SELECT ...) |
Date: | 2020-09-26 06:37:13 |
Message-ID: | CAA4eK1KyftVDgovvRQmdV1b=nN0R-KqdWZqiu7jZ1GYQ7SO9OA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 25, 2020 at 9:11 AM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> > > What if this
> > > ends up being invoked from inside C code?
> > >
> >
> > I think it shouldn't be a problem unless one is trying to do something
> > like insert into foreign key table. So, probably we can have an Assert
> > to catch it if possible. Do you have any other idea?
> >
>
> Note that the planner code updated by the patch does avoid creating a
> Parallel INSERT plan in the case of inserting into a table with a
> foreign key (so commandIds won't be created in the parallel-worker
> code).
> I'm not sure how to distinguish the "invoked from inside C code" case though.
>
I think if possible we can have an Assert to check if it is a
parallel-worker and relation has a foreign-key. Similarly, we can
enhance the check for any other un-safe use. This will prevent the
illegal usage of inserts via parallel workers.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2020-09-26 07:06:17 | Re: Dynamic gathering the values for seq_page_cost/xxx_cost |
Previous Message | Amit Kapila | 2020-09-26 06:16:15 | Re: Logical replication from PG v13 and below to PG v14 (devel version) is not working. |