Re: Re: BUG #13739: Recurring corrupted page pointer panics on hot-standby replica

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