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
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 |