Re: Don't try fetching future segment of a TLI.

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Don't try fetching future segment of a TLI.
Дата
Msg-id 20200407081732.GC6655@paquier.xyz
обсуждение исходный текст
Ответ на Re: Don't try fetching future segment of a TLI.  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
On Tue, Apr 07, 2020 at 12:15:00PM +0900, Fujii Masao wrote:
> I understood the situation and am fine to back-patch that. But I'm not sure
> if it's fair to do that. Maybe we need to hear more opinions about this?
> OTOH, feature freeze for v13 is today, so what about committing the patch
> in v13 at first, and then doing the back-patch after hearing opinions and
> receiving many +1?

I have not looked at the patch so I cannot say much about it, but it
is annoying to fetch segments you are not going to need anyway if you
target recovery with a timeline older than the segments fetched and
this has a cost when you pay for the bandwidth of your environment
with only one archive location.  So a backpatch sounds like a good
thing to do even if recovery is not broken per-se, only slower.

Designing a TAP test for that is tricky, but you could look at the
logs of the backend to make sure that only the wanted segments are
fetched with a central archived solution and multiple timelines
involved.  And costly it is.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [patch] Fix pg_checksums to allow checking of offline basebackup directories
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)