Jigar Shah writes:
> We had some disk issues on the primary, but raid verification corrected
> those blocks. That may have caused the primary to be corrupt.
"corrected" for small values of "corrected", I'm guessing :-(
> I have identified the objects, they both are indexes
> relname
We had some disk issues on the primary, but raid verification corrected
those blocks. That may have caused the primary to be corrupt.
I have identified the objects, they both are indexes
relname | relfilenode | relkind
+-+-
feedback_pac
Jigar Shah writes:
> Postgres version = 9.1.2
Um, you do realize this is over a year out of date right?
(Fortunately, you will have an excellent opportunity to update tomorrow.)
> Few days ago we had a situation where our Primary started to through the
> error messages below indicating corrupti
You should figure out what base/16384/114846.39 corresponds to inside
the database. If you're super lucky its something unimportant and/or
something that can be recreated easily (like an index). If its
something important, then you're only option is to try to drop the
object and restore it from t
Hi,
Postgres version = 9.1.2
OS = debian(6.0.7)
fsync = on
full_page_writes = on
Setup = Primary and streaming replication based secondary
Few days ago we had a situation where our Primary started to through the error
messages below indicating corruption in the database. It crashed sometimes and
Hi,
Few days ago we started getting the below message and postgres on our
server(streaming replication secondary) would not startup. I am wondering what
are our options at this point. Can we do something to fix this?
2013-03-27 11:00:47.281 PDT LOG: recovery restart point at 161A/17108AA8
2013
