Re: ERROR: cannot start subtransactions during a parallel operation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ERROR: cannot start subtransactions during a parallel operation
Date
Msg-id CA+TgmobYEPxPFwdaT5zp=Tx94Hkze6jDr_msLVSSymZm3DBtHA@mail.gmail.com
Whole thread Raw
In response to Re: ERROR: cannot start subtransactions during a parallel operation  (Mai Peng <maily.peng@webedia-group.com>)
List pgsql-hackers
On Sun, Jul 1, 2018 at 5:02 AM, Mai Peng <maily.peng@webedia-group.com> wrote:
> Hello, how could I relax the subtransaction restriction, I used the Parallel
> Unsafe option, but still have the same issue.

There's no user option for that.  Somebody would need to enhance
PostgreSQL by writing a patch.

I agree with Andres that the issue of XID-assignment needs to be
considered.  There are probably separate guards against that problem,
though, so it may not be an issue.  But somebody really ought to go
through xact.c and see if they can find any other problems - e.g.
whether
nParallelCurrentXids/ParallelCurrentXids will work properly, whether
any places check the current transaction for a parallel-in-progress
status rather than the top-transaction, whether aborting out of
multiple a subtransaction works directly from a parallel worker.  As
the comment says:

        /*
         * Workers synchronize transaction state at the beginning of
each parallel
         * operation, so we can't account for new subtransactions after that
         * point. We might be able to make an exception for the type of
         * subtransaction established by this function, which is
typically used in
         * contexts where we're going to release or roll back the subtransaction
         * before proceeding further, so that no enduring change to the
         * transaction state occurs. For now, however, we prohibit
this case along
         * with all the others.
         */

I think that at the time I wrote that comment (and I believe I was the
one who did write it) I mostly didn't have the time to do a careful
investigation for lurking problems, and it seemed better to be
conservative.  But it's quite possible that there is nothing to do
other than remove that error check.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: branches_of_interest.txt
Next
From: Andrew Dunstan
Date:
Subject: Re: branches_of_interest.txt