Re: BUG #17035: assert after commit
От | RekGRpth |
---|---|
Тема | Re: BUG #17035: assert after commit |
Дата | |
Msg-id | CAPgh2mKqhomO0O0ciMc57sp13Jp0hZCLdR7MbL_mEvT3VrbT1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17035: assert after commit (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17035: assert after commit
|
Список | pgsql-bugs |
Ok, I see. But I use SPI_execute_plan in background worker and no ActivePortal there with bst regrds, Rek>pth ср, 26 мая 2021 г. в 22:47, Tom Lane <tgl@sss.pgh.pa.us>: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > Hmm, see for example [1] which is doing SPI_prepare_my() [2] and then > > SPI_execute_plan_my() ... Does the SPI interface really require that you > > create an ActivePortal in the SPI-calling code? > > The expectation is that the calling code is already executing inside > some Portal. If it isn't, it's incumbent on the caller to set up > an adequate substitute environment, in particular a transaction > snapshot. The only thing 84f5c2908 changed is that now you get > a guaranteed failure if you neglect to provide that, rather than > failing only in corner cases. > > Possibly we should change that Assert to an elog that tries to > make it clear that the blame is on the caller. > > regards, tom lane
В списке pgsql-bugs по дате отправления: