| From: | Greg Nancarrow <gregn4422(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(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-25 03:40:47 |
| Message-ID: | CAJcOf-fqL++J6D16F5CV0wHLMj6rMtHY4h2wja6Sfrt4keJA2w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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.
Regards,
Greg Nancarrow
Fujitsu Australia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Zhang | 2020-09-25 04:00:19 | Re: history file on replica and double switchover |
| Previous Message | Michael Paquier | 2020-09-25 03:32:22 | Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 |