Re: Recovery inconsistencies, standby much larger than primary

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>
Subject: Re: Recovery inconsistencies, standby much larger than primary
Date: 2014-01-31 21:11:51
Message-ID: 21858.1391202711@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> One thing I keep coming back to is a bad ran chip setting a bit in the
> block number. But I just can't seem to get it to add up. The difference is
> not a power of two, it had happened on two different machines, and we don't
> see other weirdness on the machine. It seems like a strange coincidence it
> would happen to the same variable twice and not to other variables.

I also looked at the bit patterns for the two block numbers, and couldn't
detect any relationship.

> Unless there's some unrelated code writing through a wild pointer, possibly
> to a stack allocated object that just happens to often be that variable?

Yeah, I'd been wondering if the WAL record somehow got corrupted while
in memory (presumably after being CRC-checked). It's a bit hard to see
how though.

Are all the bloated-on-the-slave relations indexes? I think the most
fruitful thing to do at this point is to try to isolate the bloating
events for the other affected rels as you've done for this one.
Maybe we'll see a pattern.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-01-31 21:28:08 Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch
Previous Message Bruce Momjian 2014-01-31 21:06:51 Re: Misplaced BKI entries in pg_amproc.h