Re: Segfaults and assertion failures with not too extraordinary views and queries
От | Phil Frost |
---|---|
Тема | Re: Segfaults and assertion failures with not too extraordinary views and queries |
Дата | |
Msg-id | 901C0A11-6F04-4185-935F-67C0F0FB5A64@macprofessionals.com обсуждение исходный текст |
Ответ на | Re: Segfaults and assertion failures with not too extraordinary views and queries (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
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@macprofessionals.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 >
В списке pgsql-bugs по дате отправления: