Disconnect from SPI manager on error

RekGRpth <rekgrpth@gmail.com> writes:

A patch fixing this bug
/messages/by-id/15738-21723084f3009ceb@postgresql.org

I do not think this code change is necessary or appropriate.
It is not plpgsql's job to clean up after other backend subsystems
during a transaction abort. Maybe if plpgsql were the only thing
that invokes spi.c, it would be sane to factorize the responsibility
this way --- but of course it is not.

The complaint in bug #15738 is 100% bogus, which is probably why
it was roundly ignored. The quoted C code is just plain wrong
about how to handle errors inside the backend. In particular,
SPI_rollback is not even approximately the right thing to do to
clean up after catching a thrown exception.

regards, tom lane

It is not plpgsql's job to clean up after other backend subsystems

during a transaction abort.
But plpgsql do clean up on success! I suggest only do cleanup and on
exception.

чт, 20 июн. 2019 г. в 20:33, Tom Lane <tgl@sss.pgh.pa.us>:

On Fri, Jun 21, 2019 at 3:45 AM RekGRpth <rekgrpth@gmail.com> wrote:

It is not plpgsql's job to clean up after other backend subsystems

during a transaction abort.
But plpgsql do clean up on success! I suggest only do cleanup and on exception.

Except that's wrong, because when an error happens, cleanup is - in
most cases - the job of (sub)transaction abort, not something that
should be done by individual bits of code.

PostgreSQL has a centralized system for processing exception cleanup
for a very good reason: there are LOTS of places where errors can be
thrown, and if each of those places has to have its own error cleanup
logic, you end up with a real mess. Instead we've gone the other way:
you can throw an error from anywhere without doing any cleanup, and
it's the job of the error-handling machinery to invoke subtransaction
abort logic, which is responsible for cleaning up whatever mess has
been left behind.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company