Re: Recovery inconsistencies, standby much larger than primary

1261982.53 is entirely nuls. I think that's true for most if not all
of the intervening files, still investigating.

The 54th segment is nul up to offset 1f0c0000 after which it has valid
looking blocks:

# hexdump 1261982.54 | head -100
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
1f0c0000 0ea1 0000 8988 0063 0006 0000 04d8 0cf0

However when I grep xlogdump for any records mentioning this block I
get nothing.

In fact the largest block I find in the xlog is 3646630:

# grep 'tid 3646631/' 1261982 | wc -l
0
# grep 'tid 3646630/' 1261982 | wc -l
177

Looking at the block above it looks like the LSN is 0000EA100638988
which I find in the logs but it's a btree insert on a different btree:

[cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
info:8, prev:EA1/635290] bkpblock[1]: s/d/r:1663/16385/1261982
blk:3634978 hole_off/len:1240/2072
[cur:EA1/638988, xid:1418089147, rmid:11(Btree), len/tot_len:18/5894,
info:8, prev:EA1/637140] insert_leaf: s/d/r:1663/16385/1364767 tid
2746914/219
[cur:EA1/638988, xid:1418089147, rmid:11(Btree), len/tot_len:18/5894,
info:8, prev:EA1/637140] bkpblock[1]: s/d/r:1663/16385/1364767
blk:2746914 hole_off/len:1180/2372
[cur:EA1/63A0A8, xid:1418089147, rmid:1(Transaction),
len/tot_len:32/64, info:0, prev:EA1/638988] d/s:16385/1663 commit at
2014-01-21 05:41:11 UTC