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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to