Cory Zue wrote:
> I was able to get the database back to a normal functional state
> using the zero_damaged_pages flag. However, after getting
> everything working and starting to use the database again, I am
> again getting "invalid page header" errors on a certain table.
>
> Does this imply the
Hi again,
I was able to get the database back to a normal functional state using
the zero_damaged_pages
flag. However, after getting everything working and starting to use the
database again, I am again getting "invalid page header" errors on a
certain table.
Does this imply there is a hardware i
(nevermind - it looks like the zero_damaged_pages setting only took for the
duration of the session)
On Fri, Dec 26, 2014 at 5:15 PM, Cory Zue wrote:
> Hi Chiru,
>
> I am trying to pg_dump the database to have a snapshot of the current
> state. I've turned on 'zero_damaged_pages' but pg_dump is
Hi Chiru,
I am trying to pg_dump the database to have a snapshot of the current
state. I've turned on 'zero_damaged_pages' but pg_dump is still failing
with an "invalid page header" error - this time from what looks like a
sequence object that is auto-setting IDs on a table. Any advice on how to
r
Hi Cory,
After recovering table turn off *zero_damaged_pages *parameter.
On Fri, Dec 26, 2014 at 9:13 PM, Cory Zue wrote:
> Hi all,
>
> Thanks for the responses. Chiru, I'm looking into your suggestion.
>
> Sameer, here is the kernel version info:
>
> Linux dimagi 2.6.32-431.20.5.el6.x86_64 #
Hi all,
Thanks for the responses. Chiru, I'm looking into your suggestion.
Sameer, here is the kernel version info:
Linux dimagi 2.6.32-431.20.5.el6.x86_64 #1 SMP Wed Jul 16 05:26:53 EDT 2014
x86_64 x86_64 x86_64 GNU/Linux
Does that seem like it could be a problematic version?
More generally -
On 23 Dec 2014 12:05, "Cory Zue" wrote:
>
> Hi all,
>
> Our postgres instance on one of our production machines has recently been
returning errors of the form "DatabaseError: invalid page header in block 1
of relation base/16384/76623" from normal queries. I've been reading that
these are often li
Hi Cory,
We have *zero_damaged_pages* parameter in PostgreSQL configuration,by
default it is set be *off*.
To recover data from corrupted table,we can turn *on* this parameter as a
super user and populate new table using dump or copy utility.
Note : The damaged pages we can't recover from table,
Hi all,
Our postgres instance on one of our production machines has recently been
returning errors of the form "DatabaseError: invalid page header in block 1
of relation base/16384/76623" from normal queries. I've been reading that
these are often linked to hardware errors, but I would like to bet
