Skip site navigation (1) Skip section navigation (2)

Re: Segfaults and assertion failures with not too extraordinary views and queries

From: Phil Frost <phil(at)macprofessionals(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Segfaults and assertion failures with not too extraordinary views and queries
Date: 2007-02-15 14:43:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Agh...I was afraid of that.

What I've found so far is at < 
general/2007-February/000056.html>, and the rest of thread in  
general. Obviously some of these problems are veil's, but for the  
test I sent previously I had deleted so it couldn't be  
blamed. I'll explore the problem more today and see if I can get a  
backtrace with a debug version and debug_assertions off.

On Feb 14, 2007, at 5:49 PM, Tom Lane wrote:

> Phil Frost <phil(at)macprofessionals(dot)com> writes:
>> I have been attempting to migrate my application from 8.1 to 8.2.3.
>> In doing so, I found some queries would always cause the postgres
>> backend to die with a segfault. I was advised to rebuild with --
>> enable-debug --enable-cassert, and so I did. The same query would now
>> cause an assertion failure instead of segfaulting.
> Hm, I see the assert failure, but this example doesn't seem to crash
> when asserts are off, and I'd not expect it to: it should either  
> work or
> elog(ERROR) in ExecRestrPos.  So maybe you've found more than one  
> issue.
> Can you get a stack trace from a case that causes a non-assert core
> dump?  (You don't need to rebuild, just set debug_assertions = 0 while
> testing.)
> 			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Phil EndecottDate: 2007-02-15 15:27:33
Subject: Fwd: Re: BUG #3002: PQexecParams only supports some commands; needs improved error reporting, documenting or fixing
Previous:From: Pelle JohanssonDate: 2007-02-15 09:55:48
Subject: BUG #3012: Wrong JOIN order when a JOIN depends on result from a LEFT JOIN.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group