Re: commit dfda6ebaec67 versus wal_keep_segments

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: commit dfda6ebaec67 versus wal_keep_segments
Дата
Msg-id 515C718A.6060409@vmware.com
обсуждение исходный текст
Ответ на Re: commit dfda6ebaec67 versus wal_keep_segments  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: commit dfda6ebaec67 versus wal_keep_segments  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On 03.04.2013 18:58, Jeff Janes wrote:
> On Tue, Apr 2, 2013 at 10:08 PM, Jeff Janes<jeff.janes@gmail.com>  wrote:
>
>> This commit introduced a problem with wal_keep_segments:
>>
>> commit dfda6ebaec6763090fb78b458a979b558c50b39b
>
> The problem seems to be that the underflow warned about is happening,
> because the check to guard it was checking the wrong thing.  However, I
> don't really understand KeepLogSeg.  It seems like segno, and hence recptr,
> don't actually serve any purpose.

Hmm, the check is actually correct, but the assignment in the
else-branch isn't. The idea of KeepLogSeg is to calculate recptr -
wal_keep_segments, and assign that to *logSegNo. But only if *logSegNo
is not already < than the calculated value. Does the attached look
correct to you?

> At some point when it is over-pruning and recycling, it recyles the log
> files that are still needed for recovery, and if the database crashes at
> that point it will not recover because it can't find either the primary
> secondary checkpoint records.

So, KeepLogSeg incorrectly sets *logSegNo to 0, and CreateCheckPoint
decrements it, causing it to underflow to 2^64-1. Now RemoveOldXlogFiles
feels free to remove every WAL segment.

- Heikki

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Regex with > 32k different chars causes a backend crash
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)