Grigory Smolkin <g.smolkin@postgrespro.ru> writes:
> It`s INSERT:
> 2016-10-07 19:41:41 MSK [11404]: [78416-1]
> user=gis,db=gis,app=psql,client=[local] STATEMENT:
> explain analyze insert into edges_snapped_speeds select gid, speed*3600,
> ts from (select * from traffic_snapped_tracks limit 2) a join lateral
> snaptopgr(geom) on true;
No, it isn't:
2016-10-07 19:41:41 MSK [11404]: [78414-1] user=gis,db=gis,app=psql,client=[local] ERROR: cannot start commands during
aparallel operation
2016-10-07 19:41:41 MSK [11404]: [78415-1] user=gis,db=gis,app=psql,client=[local] CONTEXT: SQL statement "SELECT
proj4textFROM spatial_ref_sys WHERE srid = 4326 LIMIT 1"
2016-10-07 19:41:41 MSK [11404]: [78416-1] user=gis,db=gis,app=psql,client=[local] STATEMENT: explain analyze insert
intoedges_snapped_speeds select gid, speed*3600, ts from (select * from traffic_snapped_tracks limit 2) a join lateral
snaptopgr(geom)on true;
This is somewhere down inside a SELECT issued by a called function.
Apparently you've got multiple levels of nested SQL operations there. The
outer INSERT wouldn't get parallelized, but a query planned and executed
inside a called function could be.
I concur with Greg's conclusion that somewhere in the stack there's a
function marked PARALLEL SAFE that shouldn't be marked that way.
But we don't have nearly enough details to identify it.
regards, tom lane