Re: parallel.c is not marked as test covered - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: parallel.c is not marked as test covered
Date
Msg-id CAA4eK1LmWXiSOYYuBKKUr0_Sy=bxM536ZBCzb+JG077FxPMNaw@mail.gmail.com
Whole thread Raw
In response to Re: parallel.c is not marked as test covered  (Noah Misch <noah@leadboat.com>)
Responses Re: parallel.c is not marked as test covered
List pgsql-hackers
On Wed, Jun 15, 2016 at 12:07 PM, Noah Misch <noah@leadboat.com> wrote:
>
> 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.

Patch implementing option (a) attached with this mail.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [BUG] pg_basebackup from disconnected standby fails
Next
From: Bernd Helmle
Date:
Subject: pg_dump vs. idle_in_transaction_session_timeout