Re: parallel.c is not marked as test covered

On 6/19/16 3:09 PM, Robert Haas wrote:
> On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Amit Kapila <amit.kapila16@gmail.com> writes:
>>> On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Would this not result in unstable test output depending on whether the
>>>> code executes in the leader or a worker?
>>
>>> Before doing that test, we set force_parallel_mode=1, so it should always
>>> execute in worker which will ensure a stable output.
>>
>> No, it *might* execute in a worker.  If you can get one.
>
> Right.

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.

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?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services