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: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: "PANIC: cannot make new WAL entries during recovery" in the wild
Date: 2009-08-07 18:50:33
Message-ID: 25973.1249671033@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> So that confirms my speculation that btree index cleanup is the source
>> of the message. We have two basic approaches to dealing with it:
>>
>> 1. Decide that the check added to XLogInsert is wrong and take it out.
>>
>> 2. Arrange for some sort of explicit state transition between the
>> WAL-reading and cleanup phases of recovery, and make sure XLogInsert
>> knows about it.

> I'd suggest we temporarily allow XLog insertion by calling
> LocalSetXLogInsertAllowed() just before the rm_cleanup() loop, and reset
> it with "LocalXLogInsertAllowed = -1" just after the loop. Like we do at
> the startup checkpoint. The sanity check still feels very useful to me,
> I'd hate to lose it.

Yeah, that looks like a sane solution. The disturbing thing is that
we didn't catch this sooner.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2009-08-07 18:51:37 Re: GRANT ON ALL IN schema
Previous Message Greg Stark 2009-08-07 18:48:15 Re: Fixing geometic calculation