From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Mai Peng <maily(dot)peng(at)webedia-group(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ERROR: cannot start subtransactions during a parallel operation |
Date: | 2018-06-29 17:22:22 |
Message-ID: | 20180629172222.liaq6giboqeozwek@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-06-29 16:50:47 +0200, Tomas Vondra wrote:
> On 06/29/2018 04:00 PM, Mai Peng wrote:
> > Hello,
> >
> > On a pG10.4 instance, my query ( a simple select from a view) throw this
> > error:
> > ERROR: cannot start subtransactions during a parallel operation
> > CONTEXT: PL/pgSQL function check_validity(ltree[]) line 4 during
> > statement block entry
> >
>
> So, what does this check_validity function do? It's not part of PostgreSQL,
> and it apparently tries to do something that opens a subtransation. Like a
> SAVEPOINT for example ...
>
> > But prefixing this query by "set max_parallel_workers_gather=0" make it
> > works.
> >
> > When I take off the column that is checked by a function, no need to add
> > set max_parallel_workers_gather=0 .
> >
>
> Well, that's not really surprising - if you disable parallelism the query is
> no longer subject to the restriction about subtransactions.
>
> > How could I continue to use the default max_parallel_workers_gather (2).
> >
>
> Modity the function not to start a subtransaction.
Wouldn't the right fix be to adjust the parallel safety of the function?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Regina Obe | 2018-06-29 17:30:03 | RE: Regression on PostgreSQL 10 ORDER/GROUP BY expression not found in targetlist |
Previous Message | Vik Fearing | 2018-06-29 17:19:38 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |