Peter Eisentraut <> writes:
> On 6/19/16 3:09 PM, Robert Haas wrote:
>> On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane <> 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to