Re: PL/pgSQL: EXCEPTION NOSAVEPOINT - Mailing list pgsql-patches

From Tom Lane
Subject Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Date
Msg-id 3882.1123102086@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/pgSQL: EXCEPTION NOSAVEPOINT  (Matt Miller <mattm@epx.com>)
List pgsql-patches
Matt Miller <mattm@epx.com> writes:
> On Wed, 2005-08-03 at 16:25 -0400, Tom Lane wrote:
>> You do not have the
>> option to continue processing after elog(ERROR); the (sub)transaction
>> rollback is necessary to clean up inconsistent state.

> Okay, I'll look at this more closely.  Can you give me an example of
> what can go wrong?

Well, for example, failure to release locks and buffer pins held by an
abandoned query.  Memory leaks.  Row versions inserted into the database
that will be seen as good because they're marked as being generated by
the outer transaction, rather than coming from a subtransaction that can
be separately marked as aborted.  Pretty much everything done by
AbortSubTransaction can be seen as cleanup...

The only way you could get the effect you are after would be to run a
new subtransaction for each executed query; which is not impossible
but the overhead would be appalling :-(

            regards, tom lane

pgsql-patches by date:

Previous
From: Matt Miller
Date:
Subject: Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Next
From: "Qingqing Zhou"
Date:
Subject: prevent encoding conversion recursive error