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

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: ruben <ruben20(at)superguai(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: SQL command to dump the contents of table failed: PQendcopy() failed. Error message from server: socket not open
Date: 2005-09-23 16:47:08
Message-ID: 20050923164708.GA80692@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthew Peter 2005-09-23 16:48:06 Re: array_dims array_lower/upper distance
Previous Message Bruce Momjian 2005-09-23 16:28:53 Re: Lines of code in PG 8.0 & 8.1?