Re: SPI: Correct way to rollback a subtransaction?

On 2/20/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
> >       BeginInternalSubTransaction(NULL);
> >       res = SPI_connect();
> >       if (res < 0)
> >               elog(ERROR, "cannot connect to SPI");

> This seems like a pretty bad idea: if the SPI_connect fails you lose
> control without having unwound the subtransaction.  That's unlikely,
> but still wrong.

But if I want the error to reach upper transaction?  SPI_connect
failure does not seem a 'expected' situation to me.

Or will the started subtransaction corrupt some state?

>         PG_CATCH();
>         {
>                 /* we expect rollback to clean up inner SPI call */
>                 RollbackAndReleaseCurrentSubTransaction();
>                 FlushErrorState();
>                 res = -1; /* remember failure */
>         }
>         PG_END_TRY();
>
> Check the abort-subtrans path but I think it gets you out of the nested
> SPI call.  (Because pl_exec.c wants to preserve an already-opened SPI
> call, it has to go out of its way to undo this via SPI_restore_connection.
> I *think* you don't need that here but am too lazy to check for sure.
> Anyway it'll be good practice for you to figure it out for yourself ;-))

Thank you for hints.  The RollbackAndReleaseCurrentSubTransaction()
seems to call AbortSubTransaction->AtEOSubXact_SPI() only if the
transaction is TBLOCK_SUBINPROGRESS,  As SERIALIZABLE seems to
thow simple elog(ERROR, ...) [executor/execMain.c], and error
handling also does not seem to touch transaction state, it seems
calling SPI_finish() is not needed.

Correct?  (Yes, I'm newbie in core code...)

--
marko