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
>