Re: random system table corruption ...
От | Hans-Juergen Schoenig |
---|---|
Тема | Re: random system table corruption ... |
Дата | |
Msg-id | 96839417-9CEC-436E-86D8-36CE0978366E@cybertec.at обсуждение исходный текст |
Ответ на | Re: random system table corruption ... (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-hackers |
alvora, what concerns me here: this is a sun system and the problem happened during normal operation. there should not be a recovery related operation. something which is also interesting: there are two corrupted pages in there (page number 22 and 26). strange thing :(. thanks a lot, hans On 11 Sep 2005, at 20:01, Alvaro Herrera wrote: > On Sun, Sep 11, 2005 at 01:12:34PM +0200, Hans-Jürgen Schönig wrote: > >> in the past we have faced a couple of problems with corrupted system >> tables. this seems to be a version independent problem which >> occurs on >> hackers' from time to time. >> i have checked a broken file and i have seen that the corrupted >> page has >> actually been zeroed out. >> > > IIRC the XFS filesystem zeroes out pages that it recovers from the > journal but did not have a fsync on them (AFAIK XFS journals only > metadata, so page creation but not the content itself). I don't think > this would be applicable to your case, because we do fsync modified > files on checkpoint, and rewrite them completely from WAL images after > that. But I thought I'd mention it. > > -- > Alvaro Herrera -- Valdivia, Chile Architect, > www.EnterpriseDB.com > "Just treat us the way you want to be treated + some extra allowance > for ignorance." (Michael Brusser) > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
В списке pgsql-hackers по дате отправления: