In service of the refactoring of error handling that I was talking about a few days ago, I'm finding that there are several places that really ought to catch longjmps and clean up after themselves, instead of expecting that whatever mess they've made will be cleaned up for them when control gets back to PostgresMain().
This is especially a problem when the cleanup needs to be done inside the embedded interpreter. I found that with R, I had to throw an error in the R interpreter in order to allow the interpreter to clean up its own state. That left me with code like this:
8<--------------------
/*
* trap elog/ereport so we can let R finish up gracefully
* and generate the error once we exit the interpreter
*/
memcpy(&save_restart, &Warn_restart, sizeof(save_restart));
if (sigsetjmp(Warn_restart, 1) != 0)
{
InError = false;
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
error("%s", "error executing SQL statement");
}[...(execute query via SPI)...] 8<--------------------
The error() call throws the R intepreter error directly, so that on exit from the R function call I do this:
8<-------------------- ans = R_tryEval(call, R_GlobalEnv, &errorOccurred);
if(errorOccurred)
{
ereport(ERROR,...
8<--------------------Does anyone have a problem with this macro syntax? The try/catch names are stolen from Java, so I'm figuring they won't terribly surprise any modern programmer, but I'm open to different names if anyone has a better idea.
Looks good to me, but I worry about being able to do what I've described above. Basically I found that if I don't allow R to clean up after itself by propagating the SPI call generated error into R, before throwing a Postgres ERROR, I wind up with core dumps. Or am I just doing something wrong here (it seems to work for all of the test cases I could think of)?
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
