Thread: PG_TRY(), PG_CATCH()....

Guys,


I've got a C-implemented function which performs number
of SPI_exec()'s in a loop, where each of them may fail,
thus I wrapped them into the PG_TRY()/PG_CATCH() inside
the loop. Something like this :

for(i = 0; i < query_count; i++) {

  PG_TRY();
  {

    SPI_exec(query[i], 1);

  }

  PG_CATCH();
  {

    FlushErrorState();

  }
  PG_END_TRY();

}

Which works fine with successful queries, but for each
unsuccessful query it complains about reference leaks
and not properly closed relations.
 Later on I've solved that with use of subtransactions, which
provide some proper cleanup mechanisms, but I was wondering
if it is possible to bypass that layer, and make the code
above work fine just by doing some cleanup within the catch
block.

Thanks!


Best regards,
Alex Vinogradovs

Alex Vinogradovs wrote:

> Which works fine with successful queries, but for each
> unsuccessful query it complains about reference leaks
> and not properly closed relations.
>  Later on I've solved that with use of subtransactions, which
> provide some proper cleanup mechanisms, but I was wondering
> if it is possible to bypass that layer, and make the code
> above work fine just by doing some cleanup within the catch
> block.

The only code that knows how to cleanup completely after transaction
failure is the subtransaction code.  If you need to do something that
may cause a transaction abort, then you must use subtransactions.

(You could of course write "your own layer" but it would duplicate
subtransaction start/abort so there wouldn't be any point.)

It's expensive, yes, but there are good reasons for that.  If you are
worried about that, I'm sure there are optimizations possible.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

No, I'm not worried about them failing. My code isn't transactional...
I'm just worried about getting whole bunch of warnings about reference
leaks.


On Tue, 2007-10-09 at 09:59 -0400, Alvaro Herrera wrote:

> The only code that knows how to cleanup completely after transaction
> failure is the subtransaction code.  If you need to do something that
> may cause a transaction abort, then you must use subtransactions.
>
> (You could of course write "your own layer" but it would duplicate
> subtransaction start/abort so there wouldn't be any point.)
>
> It's expensive, yes, but there are good reasons for that.  If you are
> worried about that, I'm sure there are optimizations possible.
>