Skip site navigation (1) Skip section navigation (2)

Re: try/catch macros for Postgres backend

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: try/catch macros for Postgres backend
Date: 2004-07-30 11:14:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:

> Joe Conway <mail(at)joeconway(dot)com> writes:
>>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:
>>[ snip ]
>>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.
> You could still do that, and perhaps even a bit more cleanly:
> 	sqlErrorOccurred = false;
> 	PG_TRY();
> 	{
> 		ans = R_tryEval(call, R_GlobalEnv, &errorOccurred);
> 	}
> 	PG_CATCH();
> 	{
> 		sqlErrorOccurred = true;
> 		/* push PG error into R machinery */
> 		error("%s", "error executing SQL statement");
> 	}
> 	PG_END_TRY();
> 	if (sqlErrorOccurred)
> 	  PG_RE_THROW();
> 	if (errorOccurred)
> 	  ereport(ERROR, "report R error here");
> (The ereport will trigger only for errors originating in R, not for
> PG errors propagated out, which exit via the RE_THROW.)
> However I wonder whether either of these really work.  What happens
> inside R's "error()" routine, exactly?  A longjmp?  It seems like this
> structure is relying on the stack not to get clobbered between elog.c's
> longjmp and R's.  Which would usually work, except when you happened to
> get a signal during those few instructions...
> It seems like what you really need is a TRY inside each of the functions
> you offer as callbacks from R to PG.  These would catch errors, return
> them as failures to the R level, which would in turn fail out to the
> tryEval call, and from there you could RE_THROW the original error
> (which will still be patiently waiting in elog.c).

For what it's worth, I think this looks really good. Especially when 
combined with the proposal discussed in the "Sketch of extending error 
handling for subtransactions in functions". PL/Java makes heavy use 
(almost all calls) of TRY/CATCH macros today so any performance 
increase, even a small one, might be significant. And the ability to 
catch an error and actually handle it, hear, hear!

Kind regards,

Thomas Hallgren

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2004-07-30 12:26:41
Subject: pgsql-server: PostgreSQL extension makefile framework ("pgxs"), by
Previous:From: Zeugswetter Andreas SB SDDate: 2004-07-30 07:57:26
Subject: Re: Point in Time Recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group