Michael Robinson wrote:
> I am somewhat surprised that BUG #13668 merits a response, and this one
> does not.
Clearly, that one was much easier to answer than yours.
> Not a bug?
> Won't fix?
> Insufficient information?
> Go away stop bothering us?
> Something else?
> Anything?
Most likely, it's either a bug in a WAL record or its replay code, or the
platform has failed to keep its promises (flipped bits, etc)
> On Tue, Oct 27, 2015 at 09:22:08AM +0000, michael(at)snupps(dot)com wrote:
> > 2015-10-24 14:16:46.489 UTC PANIC: corrupted page pointers: lower = 17,
> > upper = 0, special = 8176
> > 2015-10-24 14:16:46.490 UTC CONTEXT: xlog redo unlink_page: rel
> > 1663/16416/254063; dead 11796080; left 1365037; right 3024097; btpo_xact
> > 64542957; leaf 2456241; leafleft 11130443; leafright 1350594; topparent
> > 4294967295
The code expects "upper" to be higher than "lower", per this check in
PageAddItem:
/*
* Be wary about corrupted page pointers
*/
if (phdr->pd_lower < SizeOfPageHeaderData ||
phdr->pd_lower > phdr->pd_upper ||
phdr->pd_upper > phdr->pd_special ||
phdr->pd_special > BLCKSZ)
ereport(PANIC,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg("corrupted page pointers: lower = %u, upper = %u, special = %u",
phdr->pd_lower, phdr->pd_upper, phdr->pd_special)));
It's likely that some previous operation set the pd_upper value to 0 --
maybe replay of an earlier WAL record.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
