Re: Assertion failure in AtCleanup_Portals

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assertion failure in AtCleanup_Portals
Date: 2012-02-07 11:21:07
Message-ID: CABOikdORwSA4Ti+iNAD0h7BjwyV57tUvEe+JHM08SHH=wc-ZEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 7, 2012 at 3:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2012-02-07 11:30:56 pg_basebackup -x stream from the standby gets stuck
Previous Message Peter Eisentraut 2012-02-07 11:20:43 Re: psql NUL record and field separator