Re: Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush - Mailing list pgsql-admin

From Wang, Mary Y
Subject Re: Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush
Date
Msg-id FA20D4C4FEBFD148B1C0CB09913825FC01EBD52E65@XCH-SW-06V.sw.nos.boeing.com
Whole thread Raw
In response to Re: Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-admin
Thanks Tom.

After talking to my co-worker, we decided to go to the last backup (we used the pg_dumpall -c command).
However, when I did enter "psql -f /usr/pgsql/backups/31.bak template1" to restore the database, I got "
psql: connectDBStart() -- connect() failed: No such file or directory
        Is the postmaster running locally
        and accepting connections on Unix socket '/tmp/.s.PGSQL.5432'?
".
I can't start my postmaster.  So how would I restore my last good backup?

Thanks in advance
Mary



-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, February 02, 2010 12:14 PM
To: Wang, Mary Y
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush

"Wang, Mary Y" <mary.y.wang@boeing.com> writes:
> Thanks for the help
> I was able to find pg_resetxlog in the path.  Are there any precautions that I need to be aware of?  Or I just don't
haveany choice? 

I'd suggest taking a tarball copy of the $PGDATA tree, so you can at least get back to where you were if it doesn't
work.

Actually ... is this RHEL 2.1 as I suspect?  If so, can you find the last RHEL 2.1 update, which was
postgresql-7.1.3-7.rhel2.1AS?
There was a fix in that that might well address your issue:

* Wed Feb 23 2005 Tom Lane <tgl@redhat.com> 7.1.3-7.rhel2.1AS
- Back-patch community 7.2 change in error recovery behavior of XLogFlush;
  this allows successful restart of the database even in the presence of
  dubious values in LSN fields of database pages.

Alternatively, if you have the ability to rebuild the version you've got, you're welcome to try adding the patch, which
isattached. 

            regards, tom lane


pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using pg_migrator to upgrade 8.3->8.4
Next
From: Jan-Peter Seifert
Date:
Subject: Re: encoding error in new Postgres version