From: | Kamigishi Rei <iijima(dot)yun(at)koumakan(dot)jp> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: BUG #17245: Index corruption involving deduplicated entries |
Date: | 2021-10-29 18:36:51 |
Message-ID: | 9c7433f6-65b3-9f57-e8a3-4414d0cf0c53@koumakan.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 29.10.2021 10:55, Kamigishi Rei wrote:
>> Do you have the log file(s) from between the 24th and now? That might
>> give us
>> a good starting point for the LSN range to scan.
>
> There are multiple WAL log files, the first of them with the timestamp
> of Oct 25 09:45.
The newly manifested issue is caught by pg_amcheck:
btree index "azurlane_wiki.mediawiki.page_main_title":
ERROR: item order invariant violated for index "page_main_title"
DETAIL: Lower index tid=(17,157) (points to heap tid=(540,5))
higher index tid=(17,158) (points to heap tid=(540,5)) page lsn=2/A019DD78.
The weird part about this is that the WAL archive does not seem to
contain any data for 157 and 158 above (in 1663/19243/274869 blk 17).
The last two entries are
rmgr: Btree len (rec/tot): 53/ 4885, tx: 2085600, lsn:
2/A0195AE0, prev 2/A01943F0, desc: INSERT_LEAF off 155, blkref #0: rel
1663/19243/274869 blk 17 FPW
rmgr: Btree len (rec/tot): 72/ 72, tx: 2085602, lsn:
2/A019DD30, prev 2/A019DCF0, desc: INSERT_LEAF off 156, blkref #0: rel
1663/19243/274869 blk 17
The WAL file in data14/pg_wal does not have anything related to 157 and
158 for this filenode/blk as well.
--
K. R.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-10-29 18:45:34 | Re: BUG #17245: Index corruption involving deduplicated entries |
Previous Message | Peter Geoghegan | 2021-10-29 18:17:19 | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |