Thanks Tomas for reporting issue and Thanks David for working on this. I can see the problem in GatherMerge, specially when nworkers_launched is zero. I will look into this issue and will post a fix for the same.
Also another point which I think we should fix is, when someone set max_parallel_workers = 0, we should also set the max_parallel_workers_per_gather to zero. So that way it we can avoid generating the gather path with max_parallel_worker = 0. Thanks, On Sat, Mar 25, 2017 at 2:21 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 25 March 2017 at 13:10, Tomas Vondra <tomas.von...@2ndquadrant.com> > wrote: > > while working on a patch I ran into some crashes that seem to be caused > by > > inconsistent handling of max_parallel_workers - queries still seem to be > > planned with parallel plans enabled, but then crash at execution. > > > > The attached script reproduces the issue on a simple query, causing > crashed > > in GatherMerge, but I assume the issue is more general. > > I had a look at this and found a bunch of off by 1 errors in the code. > > I've attached a couple of patches, one is the minimal fix, and one > more complete one. > > In the more complete one I ended up ditching the > GatherMergeState->nreaders altogether. It was always the same as > nworkers_launched anyway, so I saw no point in it. > Here I've attempted to make the code a bit more understandable, to > prevent further confusion about how many elements are in each array. > Probably there's more that can be done here. I see GatherState has > nreaders too, but I've not looked into the detail of if it suffers > from the same weirdness of nreaders always matching nworkers_launched. > > > -- > David Rowley http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Rushabh Lathia
