Re: Disconnect from SPI manager on error

Поиск
Список
Период
Сортировка
От RekGRpth
Тема Re: Disconnect from SPI manager on error
Дата
Msg-id CAPgh2mJ7vpgVPf2m=8U0+KNbkD-L4fPXdwytQjKHqfMx1A4wKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Disconnect from SPI manager on error  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Disconnect from SPI manager on error  (Robert Haas <robertmhaas@gmail.com>)
Список 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@sss.pgh.pa.us>:
RekGRpth <rekgrpth@gmail.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: clean up docs for v12
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: unlogged sequences