Re: ERROR: cannot start subtransactions during a parallel operation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mai Peng <maily(dot)peng(at)webedia-group(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ERROR: cannot start subtransactions during a parallel operation
Date: 2018-07-02 12:14:59
Message-ID: CA+TgmobYEPxPFwdaT5zp=Tx94Hkze6jDr_msLVSSymZm3DBtHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 1, 2018 at 5:02 AM, Mai Peng <maily(dot)peng(at)webedia-group(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-07-02 12:18:22 Re: branches_of_interest.txt
Previous Message Robert Haas 2018-07-02 12:05:22 Re: branches_of_interest.txt