Re: Database corruption? - Mailing list pgsql-general

From Tom Lane
Subject Re: Database corruption?
Date
Msg-id 28429.1003797438@sss.pgh.pa.us
Whole thread Raw
In response to Database corruption?  (Alvaro Herrera <alvherre@atentus.com>)
List pgsql-general
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> Um, Vadim?  Still of the opinion that elog(STOP) is a good idea here?
>> That's two people now for whom that decision has turned localized
>> corruption into complete database failure.  I don't think it's a good
>> tradeoff.

> One is able to use pg_resetxlog so I don't see point in removing elog(STOP)
> there. What do you think?

Well, pg_resetxlog would get around the symptom, but at the cost of
possibly losing updates that are further along in the xlog than the
update for the corrupted page.  (I'm assuming that the problem here is a
page with a corrupt LSN.)  I think it's better to treat flush request
past end of log as a DEBUG or NOTICE condition and keep going.  Sure,
it indicates badness somewhere, but we should try to have some
robustness in the face of that badness.  I do not see any reason why
XLOG has to declare defeat and go home because of this condition.

            regards, tom lane

pgsql-general by date:

Previous
From: "John Fabiani"
Date:
Subject: Re: Stored procedure
Next
From: Steven Vajdic
Date:
Subject: Postgres 7.1.3. installation on Windows platforms