Re: parallel.c is not marked as test covered

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