Re: parallel.c is not marked as test covered

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> 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:
>>> 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.

I would guess that 90 to 95 times out of 100, that test *will* exercise
what it's supposed to, and that's enough to make it useful. But we can't
assume that it'll happen 100% of the time.

> 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.

Agreed, if the percentage suddenly fell to 0 we wouldn't know it, and
that's concerning. But wishing it were 100% doesn't make it so.

Depending on what the percentage actually is, maybe we could treat
this like the "random" test, and allow a failure to be disregarded
overall? But that doesn't seem very nice either, in view of our
increasing reliance on automated testing. If "random" were failing
90% of the time on some buildfarm critters, that would probably
indicate a real problem, but we'd likely not realize it for a long time.

> 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?

Good question.

regards, tom lane