Re: "PANIC: cannot make new WAL entries during recovery" in the wild
От | Tom Lane |
---|---|
Тема | Re: "PANIC: cannot make new WAL entries during recovery" in the wild |
Дата | |
Msg-id | 5710.1249594560@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "PANIC: cannot make new WAL entries during recovery" in the wild (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Greg Stark <gsstark@mit.edu> writes: > 2009/8/6 Alvaro Herrera <alvherre@commandprompt.com>: > 2009-08-05 11:58:19 COTLOG: �la direcci�n de p�gina 0/6D374000 en el > archivo de registro 0, segmento 117, posici�n 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
В списке pgsql-hackers по дате отправления: