Re: parallel.c is not marked as test covered

From: Noah Misch <noah(at)leadboat(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Clément Prévost <prevostclement(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parallel.c is not marked as test covered
Date: 2016-06-15 06:37:36
Message-ID: 20160615063736.GA1030423@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote:
> In short, this test doesn't serve it's purpose which is to generate an
> error from worker.

That's bad. Thanks for figuring out the problem.

> do $$begin
> Perform stringu1::int2 from tenk1 where unique1 = 1;
> end$$;
>
> ERROR: invalid input syntax for integer: "BAAAAA"
> CONTEXT: parallel worker, PID 4460
> SQL statement "SELECT stringu1::int2 from tenk1 where unique1 = 1"
> PL/pgSQL function inline_code_block line 2 at PERFORM
>
> Considering above analysis is correct, we have below options:
> a. Modify the test such that it actually generates an error and to hide the
> context, we can exception block and raise some generic error.
> b. Modify the test such that it actually generates an error and to hide the
> context, we can use force_parallel_mode = regress;

Either of those sounds okay. No need to raise a generic error; one can raise
SQLERRM to keep the main message and not the context. I lean toward (a) so we
have nonzero test coverage of force_parallel_mode=on.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-06-15 06:41:29 Re: Reviewing freeze map code
Previous Message Amit Kapila 2016-06-15 06:20:33 Re: parallel.c is not marked as test covered