Disconnect from SPI manager on error
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t40812psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 07:31 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t40812_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t40812_1 && git checkout t40812_1Patchset v1 (message #1) is on t40812_1
A patch fixing this bug
/messages/by-id/15738-21723084f3009ceb@postgresql.org
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>:
Show quoted text
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
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