Re: [bug fix] Cascaded standby cannot start after a clean shutdown

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [bug fix] Cascaded standby cannot start after a clean shutdown
Дата
Msg-id 20180314052753.GA16179@paquier.xyz
обсуждение исходный текст
Ответ на RE: [bug fix] Cascaded standby cannot start after a clean shutdown  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Ответы RE: [bug fix] Cascaded standby cannot start after a clean shutdown  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Список pgsql-hackers
On Tue, Feb 27, 2018 at 05:15:29AM +0000, Tsunakawa, Takayuki wrote:
> That was my first thought, and I gave it up.  As you say,
> XLogReadRecord() could allocate up to 1 GB of memory for a garbage.
> That allocation can fail due to memory shortage, which prevents the
> recovery from proceeding.

Even with that, the resulting patch is sort of ugly...  So it seems to
me that the conclusion to this thread is that there is no clear winner,
and that the problem is so unlikely to happen that it is not worth the
performance impact to zero all the WAL pages fetched.  Still, the
attached has the advantage to not cause the startup process to fail
suddendly because of the allocation failure but to fail afterwards when
validating the record's contents, which has the disadvantage to allocate
temporarily up to 1GB of memory for some of the garbage, but that
allocation is short-lived.  So that would switch the failure from a
FATAL allocation failure taking down Postgres to something which will
fetching of new WAL records to be tried again.

All in all, that would be a win for the case reported on this thread.

Thoughts from anybody?
--
Michael

Вложения

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

Предыдущее
От: Tatsuro Yamada
Дата:
Сообщение: Re: planner bug regarding lateral and subquery?
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: Faster inserts with mostly-monotonically increasing values