On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 01/26/2015 05:14 PM, Tom Lane wrote:
>>
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>>
>>> 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
>>> I am thinking, so solution
>>
>>
>>> /* if we are doing RAISE, don't report its location */
>>> if (estate->err_text == raise_skip_msg)
>>> return;
>>
>>
>>> is too simple, and this part should be fixed. This change can be done by
>>> on
>>> plpgsql or libpq side. This is bug, and it should be fixed.
>>
>>
>> Doing this in libpq is utterly insane. It has not got sufficient context
>> to do anything intelligent. The fact that it's not intelligent is exposed
>> by the regression test changes that the proposed patch causes, most of
>> which do not look like improvements.
>
> How can the server know if the client wants to display context information?
It doesn't have to if the behavior is guarded with a GUC. I just
don't understand what all the fuss is about. The default behavior of
logging that is well established by other languages (for example java)
that manage error stack for you should be to:
*) Give stack trace when an uncaught exception is thrown
*) Do not give stack trace in all other logging cases unless asked for
I would be happy to show you the psql redirected output logs from my
nightly server processes that spew into the megabytes because of
logging various high level steps (did this, did that). I can't throw
the verbose switch to terse because if the error happens to be
'Division by Zero', or some other difficult to trace problem then I'm
sunk. I believe the protocol decision to 'always send context' needs
to be revisited; if your server-side codebase is large and heavily
nested it makes logging an expensive operation even if the client
strips off the log.
plpgsql.min_context seems like the ideal solution to this problem; it
can be managed on the server or the client and does not require new
syntax. If we require syntax to slip and and out of debugging type
operations the solution has missed the mark IMNSHO.
merlin
