From: | RekGRpth <rekgrpth(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Disconnect from SPI manager on error |
Date: | 2019-06-21 04:49:10 |
Message-ID: | CAPgh2mJ7vpgVPf2m=8U0+KNbkD-L4fPXdwytQjKHqfMx1A4wKQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>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(at)sss(dot)pgh(dot)pa(dot)us>:
> RekGRpth <rekgrpth(at)gmail(dot)com> writes:
> > A patch fixing this bug
> >
> https://www.postgresql.org/message-id/flat/15738-21723084f3009ceb%40postgresql.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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-06-21 05:31:52 | Re: unlogged sequences |
Previous Message | Tom Lane | 2019-06-21 01:54:46 | Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist |