More information,
I'd like to use pg_dump or pg_dumpall to dump my data. How would I do that if
I can't even start the postmaster?
I saw someone mentioned about using pg_resetxlog $PGDATA so that he would do a
pg_dump. Is that the only option that I have? If so, what are some of the
cautions that I need to be aware? Any ideas?
Here is my pgcontrol info:
--
_control version number:71
Catalog version number: 200101061
Database state: SHUTDOWNING
pg_control last modified: Tue Feb 2 08:19:14 2010
Current log file id: 2
Next log file segment:249
Latest checkpoint location: 2/F8D581BC
Prior checkpoint location:2/F8D49A34
Latest checkpoint's REDO location:2/F8D581BC
Latest checkpoint's UNDO location:0/0
Latest checkpoint's StartUpID:210
Latest checkpoint's NextXID: 79276624
Latest checkpoint's NextOID: 4412280
Time of latest checkpoint:Tue Feb 2 06:50:48 2010
Database block size: 8192
Blocks per segment of large relation: 131072
LC_COLLATE: en_US
LC_CTYPE: en_US
---
In my pg_xlog directory, I've:
total 32808
-rw---1 postgres postgres 16777216 Feb 2 06:54 000200F8
-rw---1 postgres postgres 16777216 Feb 1 10:51 000200F9
Thanks for any help.
Mary Y Wang
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Wang, Mary Y
Sent: Tuesday, February 02, 2010 9:56 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Startup proc 30595 exited with status 512 - abort and FATAL
2: XLogFlush
Importance: High
Hi,
Sorry for the double posting.
I'm having a bad day. My Postgresql has this error FATAL 2: XLogFlush:
request is not satisfied. I tried to follow the instructions from a thread
about looking for a core dump, but when I tried to start the postmaster, I got
/usr/bin/postmaster: Startup proc 30595 exited with status 512 - abort.
How do I find the corrupted record? If that is the case.
I'm pg version is postgresql-7.1.3-2. What are my options?
This is from the log file:
DEBUG: database system was shut down at 2010-02-01 19:24:40 PST
DEBUG: CheckPoint record at (2, 4173828852)
DEBUG: Redo record at (2, 4173828852); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 79259759; NextOid: 4395896
DEBUG: database system is in production state Smart Shutdown request at Mon
Feb 1 20:08:59 2010
DEBUG: shutting down
DEBUG: database system is shut down
DEBUG: database system shutdown was interrupted at 2010-02-02 07:54:51 PST
DEBUG: CheckPoint record at (2, 4174741948)
DEBUG: Redo record at (2, 4174741948); Undo record at (0, 0); Shutdown FALSE
DEBUG: NextTransactionId: 79276624; NextOid: 4412280
DEBUG: database system was not properly shut down; automatic recovery in
progress...
DEBUG: redo starts at (2, 4174742012)
DEBUG: ReadRecord: record with zero len at (2, 4174768976)
DEBUG: redo done at (2, 4174768916)
FATAL 2: XLogFlush: request is not satisfied
/usr/bin/postmaster: Startup proc 30708 exited with status 512 - abort
DEBUG: database system shutdown was interrupted at 2010-02-02 08:11:50 PST
DEBUG: CheckPoint record at (2, 4174741948)
DEBUG: Redo record at (2, 4174741948); Undo record at (0, 0); Shutdown FALSE
DEBUG: NextTransactionId: 79276624; NextOid: 4412280
DEBUG: database system was not properly shut down; automatic recovery in
progress...
DEBUG: redo starts at (2, 4174742012)
DEBUG: ReadRecord: record with zero len at (2, 4174768976)
DEBUG: redo done at (2, 4174768916)
FATAL 2: XLogFlush: request is not satisfied
/usr/bin/postmaster: Startup proc 30722 exited with status 512 - abort
DEBUG: database system shutdown was interrupted at 2010-02-02 08:18:59 PST
DEBUG: CheckPoint record at (2, 4174741948)
DEBUG: Redo record at (2, 4174741948); Undo record at (0, 0); Shutdown FALSE
DEBUG: NextTransactionId: 79276624; NextOid: 4412280
DEBUG: database system was not properly shut down; automatic recovery in
progress...
DEBUG: redo starts at (2, 4174742012)
DEBUG: ReadRecord: record with zero len at (2, 4174768976)
DEBUG: redo done at (2, 4174768916)
FATAL 2: XLogFlush: request is not satisfied
/usr/bin/postmaster: Startup proc 30788 exited with status 512 - abort
**
Thanks in advance.
Mary
Mary Y Wang
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
changes to your
