Thread: elog in 7.4

Hi!

I have a error callback function registered to run each time an SQL
error occurs. The problem is that the errfinish() calls it both if the
executed SQL statement was wrong, and if the statem,ent or plan logging
is enabled, and it seems elog.h doesn't provide the API to find out the
reason why my callback was called. I see that version 8.0 has lots of
improvements on this area.

Why does errfinish() do this? Will I break something if I modify it to
call the callbacks only on ERROR and FATAL events?

Thanks,
Laszlo

Laszlo Hornyak <kocka@forgeahead.hu> writes:
> I have a error callback function registered to run each time an SQL 
> error occurs. The problem is that the errfinish() calls it both if the 
> executed SQL statement was wrong, and if the statem,ent or plan logging 
> is enabled, and it seems elog.h doesn't provide the API to find out the 
> reason why my callback was called.

I suspect you are abusing the callback mechanism to do something it was
not intended for.  Callbacks are supposed to supply information for the
error message context field, *and nothing else*.  You'll probably break
things if you go outside that charter.  Accordingly, I see no reason why
a callback should care why it was called.

What are you trying to accomplish, really?
        regards, tom lane

Laszlo Hornyak <kocka@forgeahead.hu> writes:
> I am implementing a java language handler. If unrecoverable error occurs,
> it needs to send a signal to the java process, so it can stop the
> execution of the stored procedure, otherwise it would stay in inconsystent
> state.

Well, an elog callback is certainly the wrong place for that.  Even if
it looked to see whether the elog call was ERROR or not, an ERROR is no
longer necessarily unrecoverable --- it might be caught inside a plpgsql
exception block, for example, and not really be an error at all from the
perspective of calling code.

The right way would be to use PG_TRY to catch the exception as it
propagates out to your own level of control.
        regards, tom lane

Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.

Thanks,
Laszlo

On Tue, 21 Sep 2004, Tom Lane wrote:

> Laszlo Hornyak <kocka@forgeahead.hu> writes:
> > I am implementing a java language handler. If unrecoverable error occurs,
> > it needs to send a signal to the java process, so it can stop the
> > execution of the stored procedure, otherwise it would stay in inconsystent
> > state.
>
> Well, an elog callback is certainly the wrong place for that.  Even if
> it looked to see whether the elog call was ERROR or not, an ERROR is no
> longer necessarily unrecoverable --- it might be caught inside a plpgsql
> exception block, for example, and not really be an error at all from the
> perspective of calling code.
>
> The right way would be to use PG_TRY to catch the exception as it
> propagates out to your own level of control.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

On Wed, Sep 22, 2004 at 03:02:22PM +0200, Laszlo Hornyak wrote:
> 
> Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
> of work.

IIRC PL/Python had a hack involving sigsetjmp (which was removed in
favor of the cleaner PG_TRY).  You could try doing that.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente"

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Wed, Sep 22, 2004 at 03:02:22PM +0200, Laszlo Hornyak wrote:
>> Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
>> of work.

> IIRC PL/Python had a hack involving sigsetjmp (which was removed in
> favor of the cleaner PG_TRY).  You could try doing that.

Indeed, PG_TRY is just formalizing something that was done already in a
few places.
        regards, tom lane

Laszlo,

> Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
> of work.
> 
I have the needed macros implemented for 7.4 in PL/Java. Look in 
src/C/pljava.h.

The exception handling in versions prior to 8.0 is very rudimentary 
though. There's (as you already discovered) no way to find the cause of 
an error. The error is reported to the caller and discarded before the 
longjmp occurs.

This *much* better in 8.0. Thank's Tom.

Regards,

Thomas Hallgren