Re: Recovery inconsistencies, standby much larger than primary
От | Greg Stark |
---|---|
Тема | Re: Recovery inconsistencies, standby much larger than primary |
Дата | |
Msg-id | CAM-w4HM63gNMkChvMaWC73u-Hfe1P3BPQWO4euT4BQMLDyuSpQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Recovery inconsistencies, standby much larger than primary (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Recovery inconsistencies, standby much larger than primary
|
Список | pgsql-hackers |
The plot thickens... Looking at the next relation I see a similar symptom of a single valid block at the end of several segments of nuls. This relation is also a btree on the same table and has a header in the near vicinity of the xlog: d9de7pcqls4ib6=# select (page_header(get_raw_page('event_data_event_id_person_id', 'main', 3631161))).* ; lsn | tli | flags | lower | upper | special | pagesize | version | prune_xid ------------+-----+-------+-------+-------+---------+----------+---------+-----------EA1/63A0A8 | 6 | 0 | 1180 | 3552 | 8176 | 8192 | 4 | 0 (1 row) And indeed it's the very next xlog record: [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
В списке pgsql-hackers по дате отправления: