Re: random system table corruption ... - Mailing list pgsql-hackers

From Hans-Juergen Schoenig
Subject Re: random system table corruption ...
Date
Msg-id 96839417-9CEC-436E-86D8-36CE0978366E@cybertec.at
Whole thread Raw
In response to Re: random system table corruption ...  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List 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 by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Constraint Type Coercion issue?
Next
From: Roman Neuhauser
Date:
Subject: Re: bug #1702: nested composite types in plpgsql