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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
