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 | 25973.1249671033@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: "PANIC: cannot make new WAL entries during recovery" in the wild (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
| Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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
В списке pgsql-hackers по дате отправления: