Re: Recovery inconsistencies, standby much larger than primary - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id CAM-w4HPJ+_tJrmN4Z1AQyBLadg=2cPDj3u7nXn_+UxKpbzZngQ@mail.gmail.com
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
So just to summarize, this xlog record:

[cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
info:8, prev:EA1/635290] insert_leaf: s/d/r:1663/16385/1261982 tid
3634978/282
[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

Appears to have been written to this location:

d9de7pcqls4ib6=# select
(page_header(get_raw_page('index_event_data_on_event_occurrence_id',
'main', 7141472))).* ;   lsn     | tli | flags | lower | upper | special | pagesize |
version | prune_xid
------------+-----+-------+-------+-------+---------+----------+---------+-----------EA1/638988 |   6 |     0 |  1240 |
3312 |    8176 |     8192 |
 
4 |         0
(1 row)

The correct location appears to have been written to by later records
(a split where it's the leftsib to be specific) so any forensic
evidence is lost:

d9de7pcqls4ib6=# select
(page_header(get_raw_page('index_event_data_on_event_occurrence_id',
'main', 3634978))).* ;   lsn     | tli | flags | lower | upper | special | pagesize |
version | prune_xid
------------+-----+-------+-------+-------+---------+----------+---------+-----------EA1/A90CF8 |   6 |     0 |   792 |
5104 |    8176 |     8192 |
 
4 |         0
(1 row)

But the record prior to that lsn is a split where the leftsib matches
that record:

[cur:EA1/A8EDE0, xid:1418089314, rmid:11(Btree),
len/tot_len:3502/7938, info:68, prev:EA1/A8D7A0] split_r:
s/d/r:1663/16385/1261982 leftsib 3634978
[cur:EA1/A8EDE0, xid:1418089314, rmid:11(Btree),
len/tot_len:3502/7938, info:68, prev:EA1/A8D7A0] bkpblock[2]:
s/d/r:1663/16385/1261982 blk:1881360 hole_off/len:892/3812

Interestingly there are a bunch of other records that also write to
that block but there are no other full page writes. That seems to
imply that the index is currently missing the leaf inserted by the
EA1/637140 record.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Bruce Momjian
Date:
Subject: Re: updated emacs configuration