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