Re: missing "SPI_finish" that isn't missing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: missing "SPI_finish" that isn't missing
Date: 2015-12-24 21:37:54
Message-ID: 19080.1450993074@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> I probably just need to learn the right coding pattern for this.
> What is it?

You can't just ignore a thrown error like that. What you'd have to do
to make this coding pattern work is to set up a subtransaction, and either
commit it in the success path or roll it back upon catching an error.
(This is not terribly well documented, but the exception-block handling
in plpgsql provides a working model to follow.) Without subtransaction
cleanup, lots of stuff will be left in incorrect states --- the unbalanced
SPI stack you're seeing is just the tip of the iceberg.

99% of the time, the path of least resistance at the C-code level is to
avoid expected error conditions in the first place, rather than try to
catch and clean up. In this example, there are plenty of ways you might
test whether "mytable" exists before risking the SPI_execute call.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2015-12-24 22:21:29 Re: Support for N synchronous standby servers - take 2
Previous Message Emre Hasegeli 2015-12-24 21:17:45 Re: BRIN cost estimate