Re: Assertion failure in AtCleanup_Portals
От | Pavan Deolasee |
---|---|
Тема | Re: Assertion failure in AtCleanup_Portals |
Дата | |
Msg-id | CABOikdORwSA4Ti+iNAD0h7BjwyV57tUvEe+JHM08SHH=wc-ZEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure in AtCleanup_Portals (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Assertion failure in AtCleanup_Portals
|
Список | pgsql-hackers |
On Tue, Feb 7, 2012 at 3:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Pavan Deolasee <pavan.deolasee@gmail.com> writes: >> If I run the following sequence of commands, I get an assertion >> failure in current HEAD. > >> postgres=# BEGIN; >> BEGIN >> postgres=# SELECT 1/0; >> ERROR: division by zero >> postgres=# ROLLBACK TO A; >> ERROR: no such savepoint >> postgres=# \q > >> The process fails when the session is closed and aborted transaction >> gets cleaned at the proc_exit time. The stack trace is as below. > > Hmm. It works fine if you issue an actual ROLLBACK command there, > so my gut reaction is that AbortOutOfAnyTransaction isn't sufficiently > duplicating the full-fledged ROLLBACK code path. No time to dig further > right now though. > It works OK for a ROLLBACK command because we create a new unnamed portal for the ROLLBACK command, silently dropping the old one if it already exists. Since the ROLLBACK command then runs successfully, we don't see the same assertion. Would it be safe to drop FAILED unnamed portals during AbortOutAnyTransaction ? May be it is if we can do that before creating a new portal for ROLLBACK command itself. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: