Re: Problems with DBI, DBD::Pg and Postgres 7.2.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Johan Mjönes <johan(dot)mjones(at)agent25(dot)se>
Cc: "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Problems with DBI, DBD::Pg and Postgres 7.2.
Date: 2002-02-23 19:19:11
Message-ID: 25787.1014491951@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?iso-8859-1?Q?Johan_Mj=F6nes?= <johan(dot)mjones(at)agent25(dot)se> writes:
> We can reproduce this as many times as we want - it always crashes on
> the same position, but no matter what the query!

Odd. The postmaster log fragment you show contains no indication that
there's anything wrong, AFAICS. Even odder, there's no complaint about
an unexpected client disconnect, so it would seem that the client side
sent a deliberate disconnect (X) command.

One idea that comes to mind is that perhaps either the client or server
side is running under "ulimit" restrictions that kick in right here.
That doesn't seem to explain your symptoms, but some related idea might
be the right answer.

It might be possible to learn something by attaching to the backend
process with gdb and setting a breakpoint at proc_exit, so you could
see where it's being called from. If it's not reacting to an "X"
command then we'd learn what is making it exit.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bart Teeuwisse 2002-02-23 19:26:04 Casting varchar to timestamp fails in plpgsql
Previous Message Tom Lane 2002-02-23 19:03:13 Re: Wierdness using SUM to add results of custom C function.