Обсуждение: skipping context for RAISE statements - maybe obsolete?
Hello
Sometimes I had a problems with identification custom exceptions in
plpgsql, because we skip collecting context
/** error context callback to let us supply a call-stack traceback*/
static void
plpgsql_exec_error_callback(void *arg)
{ PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;
/* if we are doing RAISE, don't report its location */ if (estate->err_text == raise_skip_msg)
return;
if (estate->err_text != NULL)
It is some what we want?
commit f690920a752fa8e59dc9536dd14194b2141163d2
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Apr 24 21:16:45 2003 +0000
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most
elogcalls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality ---
eg,how much stuff should appear in the postmaster log? And what API should libpq expose for it?
It is not consistent behave - although I can understand some filtering
for NOTICE level messages. Can we change this behave? Mainly for
ERROR level exceptions.
Regards
Pavel Stehule
Pavel Stehule <pavel.stehule@gmail.com> writes: > /* if we are doing RAISE, don't report its location */ > if (estate->err_text == raise_skip_msg) > return; > It is some what we want? My recollection is that that special case was added because people complained about the "noise" from location lines otherwise: there are too many applications using RAISE to report user errors, for which a traceback would just be useless noise. I dug around in the archives a bit but couldn't find the original discussion. But I did find a fairly recent complaint that it's still too noisy (rather than not noisy enough): http://archives.postgresql.org/pgsql-hackers/2011-10/msg00838.php At the end of that thread we discussed adding a RAISE option to control the behavior, but nothing's been done about it. regards, tom lane
2012/12/11 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> /* if we are doing RAISE, don't report its location */ >> if (estate->err_text == raise_skip_msg) >> return; > >> It is some what we want? > > My recollection is that that special case was added because people > complained about the "noise" from location lines otherwise: there are > too many applications using RAISE to report user errors, for which a > traceback would just be useless noise. I dug around in the archives a > bit but couldn't find the original discussion. But I did find a fairly > recent complaint that it's still too noisy (rather than not noisy > enough): > http://archives.postgresql.org/pgsql-hackers/2011-10/msg00838.php > > At the end of that thread we discussed adding a RAISE option to control > the behavior, but nothing's been done about it. I can understand to this idea - but it don't work yet, respective it working only for one level of call. If you get exception from nested call, then you get CONTEXT from custom exception too: Some flag of RAISE statement can be solution, but I don't like it. Probably you would to change behave for all RAISE statements in function - not individually for one or second. And when you debug some application, you probably invite any solution that ensure change without necessity to modify function's source code. I know so GUC are limited, but in this cases, it has a minimal impact to data - and it can be ajusted on database, session, function level. A analogy is our solution for SQL identifiers and plpgsql variables solving collisions - it is best, and I newer heard about any issue. Regards Pavel Stehule > > regards, tom lane
Pavel Stehule <pavel.stehule@gmail.com> writes:
> Some flag of RAISE statement can be solution, but I don't like it.
> Probably you would to change behave for all RAISE statements in
> function - not individually for one or second. And when you debug some
> application, you probably invite any solution that ensure change
> without necessity to modify function's source code. I know so GUC are
> limited, but in this cases, it has a minimal impact to data - and it
> can be ajusted on database, session, function level.
I think this is entirely wrong. The use-case for suppressing the
context lines is where you have a "user facing" RAISE message, as
opposed to an "internal" failure where you want the context to help you
debug why the failure happened. IMO there is no reason whatever to
suppose that all or none of the RAISEs in a particular function are
user-facing cases. A mixture of internal errors and user-facing errors
is certainly common enough in our backend code, why would it be
different for plpgsql functions?
The argument that a GUC would require less application code change is
equally nonsense, since you'd have to add SET clauses to each function
to determine the behavior. The only way you'd not end up doing that is
if an *entire application* had only user-facing or only internal errors,
which doesn't seem like a likely scenario at all.
Another point is that if you decorated only some of your functions with
SET clauses, you'd end up with action-at-a-distance with the behavior of
individual RAISEs in undecorated functions depending on the call path.
This seems unlikely to work pleasantly.
> A analogy is our
> solution for SQL identifiers and plpgsql variables solving collisions
> - it is best, and I newer heard about any issue.
I don't find that to be a relevant precedent at all. For one thing,
there's nothing corresponding to the idea that some RAISEs might want
one behavior and some another even within the same function. I also
note that we did provide a non-GUC way of dealing with that problem;
the GUC way was meant as a quick stopgap for people who'd not yet
looked at their issues more closely.
regards, tom lane
2012/12/11 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> Some flag of RAISE statement can be solution, but I don't like it. >> Probably you would to change behave for all RAISE statements in >> function - not individually for one or second. And when you debug some >> application, you probably invite any solution that ensure change >> without necessity to modify function's source code. I know so GUC are >> limited, but in this cases, it has a minimal impact to data - and it >> can be ajusted on database, session, function level. > > I think this is entirely wrong. The use-case for suppressing the > context lines is where you have a "user facing" RAISE message, as > opposed to an "internal" failure where you want the context to help you > debug why the failure happened. IMO there is no reason whatever to > suppose that all or none of the RAISEs in a particular function are > user-facing cases. A mixture of internal errors and user-facing errors > is certainly common enough in our backend code, why would it be > different for plpgsql functions? > > The argument that a GUC would require less application code change is > equally nonsense, since you'd have to add SET clauses to each function > to determine the behavior. The only way you'd not end up doing that is > if an *entire application* had only user-facing or only internal errors, > which doesn't seem like a likely scenario at all. I don't understand - I can set flags for related function via ALTER FUNCTION and I don't need to change source code. I can do it as DBA with DBA tools. > > Another point is that if you decorated only some of your functions with > SET clauses, you'd end up with action-at-a-distance with the behavior of > individual RAISEs in undecorated functions depending on the call path. > This seems unlikely to work pleasantly. we can enhance RAISE with flags WITHOUT CONTEXT or some similar, but default behave should be same for custom and internal exceptions... Current behave is little bit strange for somebody who doesn't know postgresql internals. He can see context sometimes and sometimes not. > >> A analogy is our >> solution for SQL identifiers and plpgsql variables solving collisions >> - it is best, and I newer heard about any issue. > > I don't find that to be a relevant precedent at all. For one thing, > there's nothing corresponding to the idea that some RAISEs might want > one behavior and some another even within the same function. I also > note that we did provide a non-GUC way of dealing with that problem; > the GUC way was meant as a quick stopgap for people who'd not yet > looked at their issues more closely. ok, so are you thinking so current behave ok and it doesn't need change? Regards Pavel > > regards, tom lane