Re: SQL command to dump the contents of table failed: PQendcopy() failed. Error message from server: socket not open - Mailing list pgsql-general

From Michael Fuhr
Subject Re: SQL command to dump the contents of table failed: PQendcopy() failed. Error message from server: socket not open
Date
Msg-id 20050923164708.GA80692@winnie.fuhr.org
Whole thread Raw
In response to Re: SQL command to dump the contents of table failed: PQendcopy()  (ruben <ruben20@superguai.com>)
Responses Re: SQL command to dump the contents of table failed: PQendcopy()
List pgsql-general
On Fri, Sep 23, 2005 at 05:11:19PM +0200, ruben wrote:
> The operating system is Red Hat Linux release 8.0 (Psyche) and
> PostgreSQL version is 7.4.6., without non-standard extensions.
>
> I cannot find any core dump in the PGDATA directory /usr/local/pgsql (I
> don't know how to debug it to get a stack trace, I'll find out).

Did you look everywhere under $PGDATA or just in that directory?
As I recall, released versions of PostgreSQL usually dump core under
$PGDATA/base/<database oid>.  However, it's also possible that your
coredumpsize resource limit prevents core dumps; you could fix that
by putting a command like "ulimit -c unlimited" in your PostgreSQL
startup script and then stopping and restarting PostgreSQL.

Once you have a core dump, you can get a stack trace with gdb:

$ gdb /path/to/postgres /path/to/core
...
(gdb) bt

If your postgres binary was built with debugging symbols then the
stack trace should show function names, file names, and line numbers.

Can you duplicate the backend crash from psql if you issue the COPY
command that pg_dump complained about?  What about if you issue a
SELECT for all records in the table?  What does "\d tablename" show
for the table in question?

--
Michael Fuhr

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Lines of code in PG 8.0 & 8.1?
Next
From: Matthew Peter
Date:
Subject: Re: array_dims array_lower/upper distance