Hi Tom,
> Given the above facts, that's what I suspect. You may have something
> like a disk controller that sometimes passes bad data. Or a bad RAM
> chip that sometimes drops bits. If it weren't a flaky-hardware kind
> of thing I'd expect the results to be reproducible.
We are indeed having some abnormal phenomenons with this controller,
especially during boot process. So we stopped postmaster, tarred everything
up and moved it to another machine, which has proven to be stable as hell.
Then we did the select-tests again:
"select ctid,* from table order by id limit 81273;"
works fine.
"select ctid,* from table order by id limit 81274;"
crashes. so far so good, we copied the inconsistency over to the other
machine, ok. Up to now we did not encounter irreproducible problems, with
81273 it works, with +1 not.
(sidenote: "select ctid,oid,* from table order by id limit 81274;" works
flawlessly, dunno why..)
On the old machine, the one with the probable corrupt controller, we deleted
all entries in ctid's 5858 to 5862 (not with "dd" but with "delete from
table where ctid in ('(5858,0)','(5858,1)', ...)").
If we now do a
"select ctid,oid,* from table order by id limit 1,81274;" (which works
flawlessly)
we see, that this tuple is in ctid (5864,12).
We could of course now delete everything from ctid 5864 and perhaps 5865 and
5866 and so on, but is this the right way? Is deletion with
delete-statements ok? Or do we have to use dd (in which case I was very
grateful if someone gave me some hints) to zero out this blocks? What else
can we do?
greetings,
Bjoern
