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