Re: Database corruption?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
Cc: Alvaro Herrera <alvherre(at)atentus(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Database corruption?
Date: 2001-10-23 00:37:18
Message-ID: 28429.1003797438@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2001-10-23 00:57:14 Re: [GENERAL] To Postgres Devs : Wouldn't changing the select
Previous Message Hiroshi Inoue 2001-10-23 00:32:29 Re: [GENERAL] To Postgres Devs : Wouldn't changing the select