Re: "PANIC: cannot make new WAL entries during recovery" in the wild

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "PANIC: cannot make new WAL entries during recovery" in the wild
Date: 2009-08-06 21:36:00
Message-ID: 5710.1249594560@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> 2009/8/6 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> 2009-08-05 11:58:19 COTLOG: la direccin de pgina 0/6D374000 en el
> archivo de registro 0, segmento 117, posicin 3620864 es inesperada
>>

> Incidentally, Google's translate gives me the impression that the
> above message corresponds to:

> if (!XLByteEQ(hdr->xlp_pageaddr, recaddr))
> {
> ereport(emode,
> (errmsg("unexpected pageaddr %X/%X in log file %u, segment %u, offset %u",
> hdr->xlp_pageaddr.xlogid, hdr->xlp_pageaddr.xrecoff,
> readId, readSeg, readOff)));
> return false;
> }

> I'm not sure what this indicates though.

It probably means nothing: this is a typical termination condition when
reading from a recycled WAL file. You come to a page that doesn't have
the expected page address, because what it's got is whatever it had in
the WAL file's previous cycle of life.

The PANIC is evidently happening during post-WAL-scanning cleanup,
perhaps while we're trying to repair incomplete btree page splits
or some such. But I don't want to speculate too much without a
stack trace.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-06 21:37:19 Re: "PANIC: cannot make new WAL entries during recovery" in the wild
Previous Message Greg Stark 2009-08-06 21:28:15 Re: "PANIC: cannot make new WAL entries during recovery" in the wild