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  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Recovery inconsistencies, standby much larger than primary
Следующее
От: Oskari Saarenmaa
Дата:
Сообщение: Re: [PATCH] pg_basebackup: progress report max once per second