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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>>> On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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