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