Agh...I was afraid of that.
What I've found so far is at <http://pgfoundry.org/pipermail/veil-
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 veil.so 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
> 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
> regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Phil Endecott||Date: 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 Johansson||Date: 2007-02-15 09:55:48|
|Subject: BUG #3012: Wrong JOIN order when a JOIN depends on result from a LEFT JOIN.|