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