pqReadData() - backend unexpectedly closed the channel

"Scott Price" <Scott.Price@sci.com> writes:

The last response I saw =
from postgresql.org to Frank was from a fellow Tom Lane asking to see a =
core dump. Since I experienced this problem I would like to send you a =
core dump of my file (which is gzipped), core.gz

No, I wanted to see a backtrace. A core dump is of no value on any
other platform than your own, especially without a copy of the same
executable you used (and no, don't send that).

regards, tom lane

(Marc, why in the world did you approve a 280k binary posting to
pgsql-general? There are going to be a lot of annoyed people...)

I can make this happen consistently with Perl DBI by placing a
$dbh->disconnect() in the DESTROY subroutine of an object. I doubt the two
issues have much in common, but there's my $.02. You might post to the list
(not me, I'm ignorant) how you managed to make this happen.

--rob

----- Original Message -----
From: "Scott Price" <Scott.Price@sci.com>
To: <pgsql-general@postgresql.org>; "<Tom Lane" <tgl@sss.pgh.pa.us>
Sent: Monday, March 12, 2001 7:56 PM
Subject: pqReadData() - backend unexpectedly closed the channel

To: Tom Lane, and Postgresql.org staff,

This is a message in response to the one sent by Frank Miles on Tue 7 Nov
2000 11:11:29 -0800 (PST).

I have been experiencing the same problem as the gentleman, Frank Miles,
when running Postgre SQL. I have been repeatedly getting "pqReadData -
backend closed the channel unexpectedly. This probably means that .... the
backend abruptly terminated before or while your request was being
processed" (or something close to those words). The last response I saw
from postgresql.org to Frank was from a fellow Tom Lane asking to see a core
dump. Since I experienced this problem I would like to send you a core dump
of my file (which is gzipped), core.gz, and if you all could give me any
explanations or recommendations, I'd appreciate it.

Postgre SQL Version 6.5.3 on i686-pc-linux-gnu, compiled by gcc
egcs-2.91.66.

My email: scott.price@sci.com

Thanks,

Scott M. Price

Rob Arnold writes:

I can make this happen consistently with Perl DBI by placing a
$dbh->disconnect() in the DESTROY subroutine of an object. I doubt the two
issues have much in common, but there's my $.02. You might post to the list
(not me, I'm ignorant) how you managed to make this happen.

Yes, the same here. You must not does this as the described in DBI
manpage (last sentence):

The database is automatically disconnected (by the
DESTROY method) if still connected when there are no
longer any references to the handle. The DESTROY
method for each driver should implicitly call rollback
to undo any uncommitted changes. This is vital
behaviour to ensure that incomplete transactions don't
get committed simply because Perl calls DESTROY on
every object before exiting. Also, do not rely on the
order of object destruction during 'global
destruction', it is undefined.

Dirk

On Mon, 12 Mar 2001, Scott Price wrote:

To: Tom Lane, and Postgresql.org staff,

This is a message in response to the one sent by Frank Miles on Tue 7 Nov 2000 11:11:29 -0800 (PST).

I have been experiencing the same problem as the gentleman, Frank Miles, when running Postgre SQL. I have been repeatedly getting "pqReadData - backend closed the channel unexpectedly. This probably means that .... the backend abruptly terminated before or while your request was being processed" (or something close to those words). The last response I saw from postgresql.org to Frank was from a fellow Tom Lane asking to see a core dump. Since I experienced this problem I would like to send you a core dump of my file (which is gzipped), core.gz, and if you all could give me any explanations or recommendations, I'd appreciate it.

Postgre SQL Version 6.5.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66.

My email: scott.price@sci.com

My dim recollection was that the underlying problem was that a table had been renamed
(bad order of operations!!), damaging one or more foreign key links. I was able to
fix it by editing a pg_dump'ed version of the database, and restoring the database
from the dump, thereby repairing the FK links.

Your problem may be different!

-frank