Andreas Seltenreich <andreas+pg@xxxxxxxxxxxxxxxxxx> writes:
> Tom Lane schrob:
>> It *might* work to put a generic "catch/report via elog" handler around
>> each one of your entry-point functions. Haven't tried it.
> Hmm, this setup worked quite stable here for some smaller educational
> projects. The snippet I used to wrap the C++ was:
> [ snip ]
> [ some later mention of calling back into the backend for, eg, palloc ]
I was with you until that last bit. Have you covered the case where
palloc or another called-back backend routine throws an elog? AFAICS
the only clean way to do that is to PG_TRY around every such call,
throw the error as a C++ throw, catch it again at the function exit
level, re-throw as a PG longjmp :-(. Aside from the sheer tedium and
error-proneness, there's the certainty of losing quite a lot of semantic
detail in the error reports. And on top of that, what if the error was
one that the backend can't recover from except by a transaction abort?
If some level of the C++ code thinks it can catch and recover from the
error, you've left things in a pretty bad state. (palloc failure
doesn't have this risk, but a lot of other error conditions do.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
