Re: pg_dump problem - Mailing list pgsql-novice

Hi Tom,

We have go postmaster writing to log now :)

Here are the errors received and the entries in the log.
pg_dump: connection not open
pg_dump: lost synchronization with server, resetting connection
pg_dump: SQL command to dump the contents of table "psiblast_round" failed: PQendcopy() failed.
pg_dump: Error message from server: FATAL:  The database system is starting up
pg_dump: The command was: COPY public.psiblast_round (id, region_db_comparison, round_number, matrix, runtime) TO stdout;

//-------- LOG ENTRY ------------------------
LOG:  server process (pid 7298) was terminated by signal 11
LOG:  terminating any other active server processes
WARNING:  Message from PostgreSQL backend:
    The Postmaster has informed me that some other backend
    died abnormally and possibly corrupted shared memory.
    I have rolled back the current transaction and am
    going to terminate your database system connection and exit.
    Please reconnect to the database system and repeat your query.
LOG:  all server processes terminated; reinitializing shared memory and semaphores
LOG:  connection received: host=[local]
FATAL:  The database system is starting up
LOG:  database system was interrupted at 2004-05-14 14:19:34 EST
LOG:  checkpoint record is at 45B/7D696774
LOG:  redo record is at 45B/7D696774; undo record is at 0/0; shutdown TRUE
LOG:  next transaction id: 1565578013; next oid: 983864340
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  ReadRecord: record with zero length at 45B/7D6967B4
LOG:  redo is not required
LOG:  database system is ready

//-----------------------------------
The  error message is different so we repeated the dump and got the same error message and the message in the log file is:

LOG:  connection received: host=[local]
LOG:  connection authorized: user=blast database=blast
LOG:  server process (pid 14195) was terminated by signal 11
LOG:  terminating any other active server processes
WARNING:  Message from PostgreSQL backend:
    The Postmaster has informed me that some other backend
    died abnormally and possibly corrupted shared memory.
    I have rolled back the current transaction and am
    going to terminate your database system connection and exit.
    Please reconnect to the database system and repeat your query.
LOG:  all server processes terminated; reinitializing shared memory and semaphores
LOG:  database system was interrupted at 2004-05-17 15:29:40 EST
LOG:  connection received: host=[local]
FATAL:  The database system is starting up
LOG:  checkpoint record is at 45B/7D6B9A8C
LOG:  redo record is at 45B/7D6B9A8C; undo record is at 0/0; shutdown FALSE
LOG:  next transaction id: 1565603031; next oid: 983872532
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  ReadRecord: record with zero length at 45B/7D6B9ACC
LOG:  redo is not required
LOG:  database system is ready

Almost identical to the previous message however the checkpoint recod, transaction and oids have changed. Has this to do with the dump process and not the entry being dumped at the time ?
Is there a way which to find out if it is a particular recod in the table which is causing this error and which one it is?
Any help would be great :)

Many thanks
Noel


Tom Lane wrote:

Noel Faux <noel.faux@med.monash.edu.au> writes: 

The erorr throw is:
pg_dump: message type 0x44 arrived from server while idle
pg_dump: dumpClasses(): SQL command failed
pg_dump: Error message from server: server closed the connection 
unexpectedly      This probably means the server terminated abnormally      before or while processing the request.
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor   

What shows up in the postmaster log when this happens?

If you're not keeping the postmaster's log output, now would be a good
time to start.  Personally I'd suggest configuring it to log to syslog;
you'll need to enable this in postgresql.conf and possibly adjust your
syslogd configuration to determine exactly where Postgres messages go.
If that seems like too much trouble, adjust the init.d start script to
send the postmaster's stderr to some file instead of /dev/null.
		regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
              http://archives.postgresql.org