Re: BUG #5055: Invalid page header error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: postgres bee <postgres_bee(at)live(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5055: Invalid page header error
Date: 2009-09-16 01:50:45
Message-ID: 26633.1253065845@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> [ long summary of all the weird and wonderful ways things can break ]
> ... unless an event is noticed that is associated with the corruption, or
> some way to reproduce it is found, there's no way to tell whether any
> given incident could be a rarely triggered Pg bug (ie: Pg writes wrong
> data, writes garbage to files, etc) or whether it's something external
> like hardware or interfering 3rd party software.

Sometimes you can get a good clue by examining the putatively damaged
blocks. For instance, we've seen cases where a block in a Postgres data
file was reported corrupt, and turned out to contain text out of the
system's mail spool. That's a pretty strong hint that either the
filesystem or the disk drive messed up and wrote a chunk of a file at
the wrong place. Isolated flipped bits would suggest memory problems
(per the cosmic-rays issue). And so on. Postgres bugs tend to have
fairly recognizable signatures too. But with no evidence to look at,
there's nothing we can do except speculate.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Craig Ringer 2009-09-16 02:10:35 Re: BUG #5058: [jdbc] Silent failure with executeUpdate()
Previous Message Robert Haas 2009-09-16 01:11:27 Re: BUG #5042: Update numeric within a rule