Re: Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush

From: "Wang, Mary Y" <mary(dot)y(dot)wang(at)boeing(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush
Date: 2010-02-02 22:29:08
Message-ID: FA20D4C4FEBFD148B1C0CB09913825FC01EBD52E65@XCH-SW-06V.sw.nos.boeing.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, February 02, 2010 12:14 PM
To: Wang, Mary Y
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] Startup proc 30595 exited with status 512 - abort and FATAL 2: XLogFlush

"Wang, Mary Y" <mary(dot)y(dot)wang(at)boeing(dot)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 have any 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(at)redhat(dot)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 is attached.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Jan-Peter Seifert 2010-02-02 23:07:48 Re: encoding error in new Postgres version
Previous Message Tom Lane 2010-02-02 21:47:17 Re: Using pg_migrator to upgrade 8.3->8.4