Re: Fwd: Re: BUG #5556: "cannot drop active portal" and "ERRORDATA_STACK_SIZE exceeded" lead to server crash

I found the issue earlier today and posted a small test case to
reproduce it:

http://archives.postgresql.org/pgsql-bugs/2010-07/msg00084.php

I must've clicked the wrong teply button as you were not CC'd on that.
Sorry.

The bug should be fixed now.

On 13/07/10 17:57, Robert Walker wrote:
>
> Attached are text files with the output from the debugging tool. The
> "startup" text file is when the backend was first started, the "crash"
> text file has content that was triggered in the tool when the crash
> occurred, and the "crash_info" text file is additional information I
> requested with "~*k" after the crash.
>
> As far as a self-contained example goes, I originally tried to make a
> simple test case but it would not crash using the imitation of the
> actual database. Because I wasn't sure what the cause of the crash was,
> it wasn't clear how to make a test case for it. Unfortunately my job
> doesn't let me expose too many details about stuff like this so I
> couldn't post the real details about the database. But I'll try to help
> as much as I can and I hope the stack traces will be helpful.
>
>
> On Tue, 13 Jul 2010 11:15 +0800, "Craig Ringer"
> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>> On 13/07/10 05:00, Robert Walker wrote:
>>
>>> The intent of what I was originally trying to do is to intentionally cause a
>>> unique constraint violation for the sake of testing to ensure that I won't
>>> get duplicate data in the final design. But when the unique violation
>>> occurs, a series of other (possibly related?) errors occur that lead to the
>>> crash.
>>
>>
>>> This application has requested the Runtime to terminate it in an unusual
>>> way.
>>> Please contact the application's support team for more information.
>>
>> It'd be really nice to have a backtrace of that. PostgreSQL binaries for
>> Windows are released with debug information, and if you can reproduce
>> the crash it's not hard to get a stack trace showing a fair bit of
>> information about the state the backend was in when it crashed.
>>
>> See:
>>
>>
>> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>>
>>
>> You'll need Debugging Tools for Windows or even better, the Visual C++
>> Express Edition. Both are free downloads. If you have a paid version of
>> Visual Studio, that's even better.
>>
>> It is very important to set your symbol path up properly, and make sure
>> that the information you collect is useful. See the instructions above.
>>
>> --
>> Craig Ringer
>>
>> Tech-related writing: http://soapyfrogs.blogspot.com/
>>
>>
>>
>>

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com