On 5/9/16 10:50 AM, Andres Freund wrote:
> I think it's a good idea to run a force-parallel run on some buildfarm
> members. But I'm rather convinced that the core tests run by all animals
> need some minimal coverage of parallel queries. Both because otherwise
> it'll be hard to get some coverage of unusual platforms, and because
> it's imo something rather relevant to test during development.
I can confirm that with force_parallel_mode = on, parallel.c does get
good test coverage. But I agree that it is a problem that this does not
happen in the default test setup.
I think we might want to have a new test file that sets
force_parallel_mode = on and just runs a few queries to give parallel.c
a small workout. For example, I find that the following test file gives
almost the same coverage as running the full test suite with f_p_m=on:
"""
SET force_parallel_mode = on;
EXPLAIN SELECT * FROM tenk1 WHERE unique1 = 1;
SELECT * FROM tenk1 WHERE unique1 = 1;
-- provoke error in worker
SELECT stringu1::int2 FROM tenk1;
"""
While we're at it, one of the things that force_parallel_mode = regress
does is remove an error context that is otherwise added to all messages:
errcontext("parallel worker, PID %d", *(int32 *) arg);
I think we should get rid of that error context altogether, except
possibly as a debugging tool, because it's an implementation detail that
does not need to be shown to users by default.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services