Re: SQL command to dump the contents of table failed: PQendcopy()

From: ruben <ruben20(at)superguai(dot)com>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: SQL command to dump the contents of table failed: PQendcopy()
Date: 2005-09-26 17:03:06
Message-ID: 433829CA.2080408@superguai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Tom and Michael:

Michael Fuhr wrote:

> 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.

I cannot find a core file, ulimit is set to unlimit. I guess I'm doing
something wrong:

-bash-2.05b$ ulimit
unlimited
-bash-2.05b$ find /usr/local/pgsql -name '*core*' -print
-bash-2.05b$

> Can you duplicate the backend crash from psql if you issue the COPY
> command that pg_dump complained about?

-bash-2.05b$ /usr/local/pgsql/bin/pg_dump -Fc -t llamadas heos -f
/home/buheos/5/llamadas3.dump
pg_dump: socket not open
pg_dump: SQL command to dump the contents of table "llamadas" failed:
PQendcopy() failed.
pg_dump: Error message from server: socket not open
pg_dump: The command was: COPY public.llamadas (cod_empresa,
fecha_llamada, tfno_origen, tfno_destino, duracion_llamada,
hora_llamada, cod_destino_llamada, cod_pais_destino,
cod_destino_internacional, franja_horaria, importe, cod_fuente,
precio_coste_llamada, observaciones_llamada, coment_llamada,
fecha_factura, num_factura, fecha_alta, fecha_ult_mod, fecha_sis_alta,
usuario_alta, i_a_alta, fecha_sis_ult_mod, usuario_ult_mod, i_a_ult_mod,
periodicidad_facturacion, cod_operador, franja_horaria_operador,
fichero_origen, cod_destino_internacional_operador) TO stdout;

> What about if you issue a SELECT for all records in the table?

heos=# select * from llamadas;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: WARNING:
terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
Failed.

In the logfile:

LOG: server process (PID 7069) was terminated by signal 11
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2005-09-26 16:49:43 CEST
LOG: checkpoint record is at 125/858E0144
LOG: redo record is at 125/858E0144; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 2270061; next OID: 30820346
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: record with zero length at 125/858E0184
LOG: redo is not required
LOG: database system is ready
LOG: unexpected EOF on client connection

> What does "\d tablename" show for the table in question?

heos=# \d llamadas;
Table "public.llamadas"
Column | Type |
Modifiers
------------------------------------+--------------------------+----------------------------------------------------
cod_empresa | smallint | not null
fecha_llamada | date |
tfno_origen | character(15) |
tfno_destino | character(15) |
duracion_llamada | integer |
hora_llamada | time without time zone |
default ('now'::text)::time(6) with time zone
cod_destino_llamada | character(1) |
cod_pais_destino | integer |
cod_destino_internacional | character(15) |
franja_horaria | character(1) |
importe | real |
cod_fuente | integer |
precio_coste_llamada | real |
observaciones_llamada | character varying(100) |
coment_llamada | character varying(100) |
fecha_factura | date |
num_factura | integer |
fecha_alta | date |
fecha_ult_mod | date |
fecha_sis_alta | timestamp with time zone |
default ('now'::text)::timestamp(6) with time zone
usuario_alta | character(10) |
i_a_alta | character(15) |
fecha_sis_ult_mod | timestamp with time zone |
usuario_ult_mod | character(10) |
i_a_ult_mod | character(15) |
periodicidad_facturacion | character(1) |
cod_operador | character(2) |
franja_horaria_operador | character(1) |
fichero_origen | character varying(100) |
cod_destino_internacional_operador | character(15) |
Indexes:
"llamadas_i01" btree (cod_empresa, fecha_llamada, tfno_origen)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Poul Møller Hansen 2005-09-26 17:09:13 Re: Error migrating from 7.4.3 to 8.0.3
Previous Message Raj Gupta 2005-09-26 16:43:28 Error migrating from 7.4.3 to 8.0.3