From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | RekGRpth <rekgrpth(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Disconnect from SPI manager on error |
Date: | 2019-06-24 15:08:20 |
Message-ID: | CA+Tgmobgzbeks7GhJm_YNnE+JZ0aBfL+P8do-URi-MzhKS8JQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 21, 2019 at 3:45 AM RekGRpth <rekgrpth(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2019-06-24 15:10:02 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Previous Message | Tom Lane | 2019-06-24 14:29:13 | Re: MAKEFLAGS in non-GNU Makefile |