bricklen <bricklen@gmail.com> writes:
> On Wed, Oct 21, 2015 at 11:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm confused by the block mentioned in the error message not having
>> anything to do with the TID sequence. I wonder whether it refers to an
>> index not the table proper. What query were you using to get this output,
>> exactly? Have you confirmed which relation has relfilenode 27244?
> Yes, it is definitely a table. There was originally an index on that table
> which threw the original error (about sibling mismatch). I dropped the
> index and attempted to recreate it, which failed. Further investigation led
> to discovery of corruption in the table.
Hm. There's still something weird about this though. Maybe there is no
data at all between pages 1226710 and 690651? Might be worth doing some
poking around with contrib/pageinspect/.
> As it stands, my next step is going to be a pg_dump of one of the
> up-to-date slaves (with corruption) but I will exclude the bad table. Given
> that I know the PK id range, I can COPY out the table's contents before and
> after the affected data. This way we can at least recover from backup if
> things get entirely borked.
Agreed, if you're gonna mess with the table files directly, it's always
smart to have a fallback plan in case you make things worse.
regards, tom lane