Re: Incorrect handling of OOM in WAL replay leading to data loss

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Incorrect handling of OOM in WAL replay leading to data loss
Дата
Msg-id ZNNBrS0BumpGCJBd@paquier.xyz
обсуждение исходный текст
Ответ на Re: Incorrect handling of OOM in WAL replay leading to data loss  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Incorrect handling of OOM in WAL replay leading to data loss  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Wed, Aug 09, 2023 at 04:13:53PM +0900, Kyotaro Horiguchi wrote:
> I'm not certain if message_deferred is a property of the error
> struct. Callers don't seem to need that information.

True enough, will remove.

> The name "XLOG_RADER_NONE" seems too generic. XLOG_READER_NOERROR will
> be clearer.

Or perhaps just XLOG_READER_NO_ERROR?

> 0002 shifts the behavior for the OOM case from ending recovery to
> retrying at the same record.  If the last record is really corrupted,
> the server won't be able to finish recovery. I doubt we are good with
> this behavior change.

You mean on an incorrect xl_tot_len?  Yes that could be possible.
Another possibility would be a retry logic with an hardcoded number of
attempts and a delay between each.  Once the infrastructure is in
place, this still deserves more discussions but we can be flexible.
The immediate FATAL is choice.
--
Michael

Вложения

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

Предыдущее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
Следующее
От: jian he
Дата:
Сообщение: Re: Extract numeric [field] in JSONB more effectively