Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > On 6/19/16 3:09 PM, Robert Haas wrote: >> On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers