Re: parallel.c is not marked as test covered

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Clément Prévost <prevostclement(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parallel.c is not marked as test covered
Date: 2016-06-20 02:00:47
Message-ID: CA+TgmobeA=8StbgxgRAfyYG-A-FUmZQQ4nc953cd7ArDRpyGAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 19, 2016 at 5:22 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> Well, the purpose of the test is to check the error passing between worker
> and leader. If we just silently revert to not doing that, then we can't
> really be sure that we're testing the right thing. We've already seen some
> instances in this thread where we figured out after some debugging that some
> construct is not actually going through the parallel infrastructure, so I'm
> afraid if we leave it like this it might silently change behavior at some
> point in the future.

I've been thinking about renaming the "single_copy" flag for Gather
nodes to something like "pipeline" or some other term that might hope
to convey that the leader won't participate unless no workers can be
launched at all, and then adding an option to force that to be used
always. That would allow better testing here, although I fear we
might be getting to a level of tinkering with parallel query that
starts to look more like feature development.

> Independent of that, it would help testing things like this if we allowed
> setting max_worker_processes to 0, instead of the current minimum 1. If
> there a reason for the minimum of 1?

I believe that's pure brain fade on my part. I think the minimum should be 0.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-20 02:05:47 Re: Parallel safety tagging of extension functions
Previous Message Robert Haas 2016-06-20 01:57:30 Re: Parallel safety tagging of extension functions