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
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 |