Re: pg_dump problem

Hi all,

We found the problem. In the table psiblast_round, there was one entry
which the feild matrix was corrupt. If we select all for this entry the
database died :(. If we selected all but the matrix the select finished.
If we selected only that entry and the matrix, the server died. So we
set the feild to "" and the problem was fixed. As to why that matrix
caused an error??? Don't know!!

Cheers
Noel

Noel Faux wrote:

> 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(dot)faux(at)med(dot)monash(dot)edu(dot)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
>>
>>
>