Re: BUG #15346: Replica fails to start after the crash
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: cyberdemn@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2018-08-22T08:11:26Z
Lists: pgsql-bugs, pgsql-hackers
On Wed, Aug 22, 2018 at 07:36:58AM +0000, PG Bug reporting form wrote: > 2018-08-22 06:22:23.633 UTC,,,54,,5b7d0114.36,23,,2018-08-22 06:22:12 > UTC,1/0,0,WARNING,01000,"page 179503104 of relation base/18055/212875 does > not exist",,,,,"xlog redo at AB3/50323E78 for Btree/DELETE: 182 > items",,,,"" > 2018-08-22 06:22:23.634 UTC,,,54,,5b7d0114.36,24,,2018-08-22 06:22:12 > UTC,1/0,0,PANIC,XX000,"WAL contains references to invalid pages",,,,,"xlog > redo at AB3/50323E78 for Btree/DELETE: 182 items",,,,"" Once recovery has reached a consistent state, the startup process would look at if there are any invalid pages tracked in a given hash table and complains loudly about them. It is not the last record or its surroundings which matter in case, but if this page has been found in one of the records replayed during recovery up to the consistent point. Do you have in any records from the WAL segments fetched a reference to this page? A page is 8kB, and the page number is 179503104, which is definitely weird as that would cause a relation file to be more than 1000GB. If the record itself is in bad shape, this may be a corrupted segment. As far as I can see you only have one incorrect page reference (see XLogCheckInvalidPages in xlog.c). > I will keep this instance around for further investigation and would be > happy to provide some more details if you need. That would be nice! -- Michael
Commits
-
Ensure correct minimum consistent point on standbys
- 65f39408ee71 9.3.25 landed
- d9638a326f72 9.4.20 landed
- f3520ff6fbf1 9.5.15 landed
- 4a9a5bb3fd2a 9.6.11 landed
- 2c8cff5dd60b 10.6 landed
- c34f8078aa35 11.0 landed
- c186ba135eca 12.0 landed
-
Prevent references to invalid relation pages after fresh promotion
- 8d68ee6f31ca 9.6.10 cited