Sean Kelly <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 0x8115eb2 in ri_BuildQueryKeyFull ()
> #1 0x8115dc2 in RI_FKey_keyequal_upd ()
Ah, you're probably running into the 7.0 bug about not coping gracefully
when the referenced table for a foreign key constraint has been dropped
or renamed. Thi
On Sun, 22 Apr 2001, [EMAIL PROTECTED] wrote:
> Can't tell much of anything from this. Can you provide a gdb backtrace
> from the corefile that the failed backend presumably left? It should be
> in $PGDATA/base/isp/core.
Please ignore my last mail, I've found some documentation.
Star
On Sun, 22 Apr 2001, [EMAIL PROTECTED] wrote:
> Can't tell much of anything from this. Can you provide a gdb backtrace
> from the corefile that the failed backend presumably left? It should be
> in $PGDATA/base/isp/core.
I have the core file but cannot remember how to make a backtrace.
Sean Kelly ([EMAIL PROTECTED]) writes:
> isp=> update domain_tbl set max_email='15' where domain='test.domain';
> pqReadData() -- backend closed the channel unexpectedly.
Can't tell much of anything from this. Can you provide a gdb backtrace
from the corefile that the failed backend presumably l
Sean Kelly ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
An statement causes postmaster to die
Long Description
I am having a problem trying to run an update on my database. The SQL that causes the
problem is listed below, a