Re: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CAA4eK1KifPZ5j4ufixUmB0yB60hLyA3JUOUzO73xyhntgPGovA@mail.gmail.com
Whole thread Raw
In response to Re: Parallel INSERT (INTO ... SELECT ...)  (Andres Freund <andres@anarazel.de>)
Responses Re: Parallel INSERT (INTO ... SELECT ...)
List pgsql-hackers
On Thu, Sep 24, 2020 at 7:51 AM Andres Freund <andres@anarazel.de> wrote:
>
> On 2020-09-22 14:55:21 +1000, Greg Nancarrow wrote:
>
>
> > diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
> > index 1585861..94c8507 100644
> > --- a/src/backend/access/heap/heapam.c
> > +++ b/src/backend/access/heap/heapam.c
> > @@ -2049,11 +2049,6 @@ heap_prepare_insert(Relation relation, HeapTuple tup, TransactionId xid,
> >        * inserts in general except for the cases where inserts generate a new
> >        * CommandId (eg. inserts into a table having a foreign key column).
> >        */
> > -     if (IsParallelWorker())
> > -             ereport(ERROR,
> > -                             (errcode(ERRCODE_INVALID_TRANSACTION_STATE),
> > -                              errmsg("cannot insert tuples in a parallel worker")));
> > -
>
> I'm afraid that this weakens our checks more than I'd like.
>

I think we need to change/remove this check to allow inserts by
parallel workers. I am not sure but maybe we can add an Assert to
ensure that it is safe to perform insert via parallel worker.

> 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?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Masahiro Ikeda
Date:
Subject: Re: New statistics for tuning WAL buffer size
Next
From: Michael Paquier
Date:
Subject: Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2