Re: ERROR: invalid page in block 1226710 of relation base/16750/27244

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: bricklen <bricklen(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: ERROR: invalid page in block 1226710 of relation base/16750/27244
Date: 2015-10-22 17:51:01
Message-ID: 56292205.4070009@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 10/22/15 11:25 AM, bricklen wrote:
> I would have liked to have had the opportunity to answer those questions
> myself but alas, in the heat of the moment some of the data useful for
> forensics was lost.

You could always roll WAL forward from the previous base backup and see
what happens.

FWIW, most times that I've experienced corruption it's percolated
through the WAL stream as well, presumably due to full_page_writes. It's
why I like making londiste part of the DR configuration for really
high-value data. Of course, if you're having corruption problems then
it's also very possible that your user data is getting crapped on too,
and logical replication won't help you terribly much there. I
investigated adding user-space row-level checksums but never actually
rolled that out. Of course now you'd just use page level checksums.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jim Nasby 2015-10-22 17:56:50 Re: temporary indexes?
Previous Message Jim Nasby 2015-10-22 17:43:42 Re: ID column naming convention