On Tue, Jun 14, 2016 at 1:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jun 14, 2016 at 12:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> FWIW, I follow all of your reasoning except this. If we believe that the >>> parallel worker context line is useful, then it is a bug that plpgsql >>> suppresses it. If we don't believe it's useful, then we should get >>> rid of it. "Do nothing" is simply not a consistent stance here. > >> Well, if PL/pgsql suppresses context and nobody's complained about >> that up until now, fixing it doesn't seem any more urgent than any >> other bug we've had for N releases. > > I have not dug into the code enough to find out exactly what's happening > in Peter's complaint, but it seems like it would be a good idea to find > that out before arguing along these lines. It seems entirely likely > to me that this is somehow parallel-query-specific. Even if it isn't, > I don't buy your argument. Adding a new case in which context is > suppressed is a perfectly reasonable basis for thinking that an old > bug has acquired new urgency.
OK. I find this whole thing slightly puzzling because Noah wrote this in the test file: -- Provoke error in worker. The original message CONTEXT contains a worker -- PID that must be hidden in the test output. PL/pgSQL conveniently -- substitutes its own CONTEXT. The phrasing of the comment implies that (1) the behavior is desirable at least for the purpose at hand and (2) the behavior is unrelated to parallel query. However, it's surely possible that (2) is false and (1) is not the consensus. Noah is usually pretty careful about this sort of thing, but he might have made a mistake. Considering that, I decide to take a look. I wasn't able in a quick test to verify that this behavior doesn't happen without parallel query. I also wasn't able to figure out exactly why it was happening. I did verify that this statement generates an error that is propagated to the leader. The expected output looks like this: ERROR: invalid input syntax for integer: "BAAAAA" CONTEXT: SQL statement "select stringu1::int2 from tenk1 where unique1 = 1" PL/pgSQL function inline_code_block line 5 at SQL statement The first line of context begins with "SQL statement" and I believe that's coming from spi.c. The second line of the context seems to come from PL/pgsql. But what accounts for the failure of the "parallel query" line to appear in the context message? This could be explained by _SPI_error_callback flushing the existing context in its handler, but it doesn't seem to do that. I guess this needs some more looking at. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers