| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Recovery inconsistencies, standby much larger than primary |
| Date: | 2014-02-02 16:44:15 |
| Message-ID: | CAM-w4HOfsA9a+tbO6b=kgeG0-BvG2xzUwOZ3dgTvKhwej=zsTA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've poked at this a bit more. There are at least 10 relations where
the last block doesn't match the block mentioned in the xlog record
that its LSN indicates. At least it looks like from the info xlogdump
prints.
Including two blocks where the "correct" block has the same LSN which
maybe means the record was correctlly replayed the second time. Or
perhaps it just means I'm underestimating the complexity of btree
splits.
[cur:EAD/511424E0, xid:1423308342, rmid:11(Btree),
len/tot_len:3750/12786, info:77, prev:EAD/51142490] split_r:
s/d/r:1663/16385/1521566 leftsib 1697585
[cur:EAD/511424E0, xid:1423308342, rmid:11(Btree),
len/tot_len:3750/12786, info:77, prev:EAD/51142490] bkpblock[1]:
s/d/r:1663/16385/1521566 blk:1697585 hole_off/len:576/4288
[cur:EAD/511424E0, xid:1423308342, rmid:11(Btree),
len/tot_len:3750/12786, info:77, prev:EAD/51142490] bkpblock[2]:
s/d/r:1663/16385/1521566 blk:786380 hole_off/len:740/3140
relfilenode | blockno | lsn | tli | flags | lower | upper |
special | pagesize | version | prune_xid
-------------+----------+--------------+-----+-------+-------+-------+---------+----------+---------+------------
1521566 | 1697585 | EAD/511456E8 | 6 | 0 | 576 | 4864 |
8176 | 8192 | 4 | 0
1521566 | 1704143 | EAD/511456E8 | 6 | 0 | 644 | 4456 |
8176 | 8192 | 4 | 0
[cur:EAD/520F0EE0, xid:1423309260, rmid:11(Btree),
len/tot_len:4230/4450, info:69, prev:EAD/520F0E98] split_r:
s/d/r:1663/16385/4995658 leftsib 139569
[cur:EAD/520F0EE0, xid:1423309260, rmid:11(Btree),
len/tot_len:4230/4450, info:69, prev:EAD/520F0E98] bkpblock[2]:
s/d/r:1663/16385/4995658 blk:18152 hole_off/len:28/8028
relfilenode | blockno | lsn | tli | flags | lower | upper |
special | pagesize | version | prune_xid
-------------+----------+--------------+-----+-------+-------+-------+---------+----------+---------+------------
4995658 | 139569 | EAD/520F2058 | 6 | 0 | 152 | 4336 |
8176 | 8192 | 4 | 0
4995658 | 139584 | EAD/520F2058 | 6 | 0 | 164 | 3976 |
8176 | 8192 | 4 | 0
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-02-02 16:52:22 | Re: mvcc catalo gsnapshots and TopTransactionContext |
| Previous Message | Andres Freund | 2014-02-02 16:43:03 | slow startup due to LWLockAssign() spinlock |