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

Поиск
Список
Период
Сортировка
От Pavel Suderevsky
Тема Re: Don't try fetching future segment of a TLI.
Дата
Msg-id CAEBTBzupObE6Gep1y-ajvUh4AjuvyTmfTewshVOei12uRV=Q8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Don't try fetching future segment of a TLI.  (David Steele <david@pgmasters.net>)
Ответы Re: Don't try fetching future segment of a TLI.  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Re: Don't try fetching future segment of a TLI.  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
Hi,

I've tested patch provided by Kyotaro and do confirm it fixes the issue.
Any chance it will be merged to one of the next minor releases?

Thank you very much!

сб, 1 февр. 2020 г. в 08:31, David Steele <david@pgmasters.net>:
On 1/28/20 8:02 PM, Kyotaro Horiguchi wrote:
 > At Tue, 28 Jan 2020 19:13:32 +0300, Pavel Suderevsky
 >> Regading influence: issue is not about the large amount of WALs to apply
 >> but in searching for the non-existing WALs on the remote storage,
each such
 >> search can take 5-10 seconds while obtaining existing WAL takes
 >> milliseconds.
 >
 > Wow. I didn't know of a file system that takes that much seconds to
 > trying non-existent files. Although I still think this is not a bug,
 > but avoiding that actually leads to a big win on such systems.

I have not tested this case but I can imagine it would be slow in
practice.  It's axiomatic that is hard to prove a negative.  With
multi-region replication it might well take some time to be sure that
the file *really* doesn't exist and hasn't just been lost in a single
region.

 > After a thought, I think it's safe and effectively doable to let
 > XLogFileReadAnyTLI() refrain from trying WAL segments of too-high
 > TLIs.  Some garbage archive files out of the range of a timeline might
 > be seen, for example, after reusing archive directory without clearing
 > files.  However, fetching such garbages just to fail doesn't
 > contribute durability or reliablity at all, I think.

The patch seems sane, the trick will be testing it.

Pavel, do you have an environment where you can ensure this is a
performance benefit?

Regards,
--
-David
david@pgmasters.net

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Internal key management system
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Add FOREIGN to ALTER TABLE in pg_dump