Re: db recovery (FATAL 2) - Mailing list pgsql-admin

From Bojan Belovic
Subject Re: db recovery (FATAL 2)
Date
Msg-id 20020508202717.1952.qmail@uwdvg023.cms.usa.net
Whole thread Raw
In response to db recovery (FATAL 2)  (Bojan Belovic <bbelovic@usa.net>)
Responses Re: db recovery (FATAL 2)
List pgsql-admin
It turns out it was a bad sector, and once the data was retreived and the
drive replaced, postgres was able to go through the startup process
sucessfully. Given that it did not report any errors on recovery, I suppose
there was no data loss, but even if there was some damage to the log file, it
should be minor - the crash happened at 6am, almost no activity, so I'm not
going to worry about that at all at this point.
Anyway, thank you very much for your help.
One quick question - you mentioned I should upgrade to 7.1.3 beofre I run
vacuum again. What are the known problems that "ask" for this?

Thanks again!


Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bojan Belovic <bbelovic@usa.net> writes:
> > You are correct, it's 7.1.2 . However, the problem is not with disk space
> > (there's several gigs available), but there could be a problem with a bad
> > sector on one of the log files. If this is the case, and the log file is
> > corrupted, is there any way of recovering, even with a certain data loss?
>
> Hm.  It's complaining about a write, not a read, so there is no lost
> data (yet), even if your theory is correct.  You might first try copying
> the entire $PGDATA/pg_xlog directory somewhere else.
>
> If nothing else avails, see contrib/pg_resetxlog.  But that should be
> your last resort not first.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html


pgsql-admin by date:

Previous
From: Laurette Cisneros
Date:
Subject: pg_ctl
Next
From: Tom Lane
Date:
Subject: Re: db recovery (FATAL 2)