Re: Don't try fetching future segment of a TLI. - Mailing list pgsql-hackers

From Pavel Suderevsky
Subject Re: Don't try fetching future segment of a TLI.
Date
Msg-id CAEBTBzupObE6Gep1y-ajvUh4AjuvyTmfTewshVOei12uRV=Q8Q@mail.gmail.com
Whole thread Raw
In response to Re: Don't try fetching future segment of a TLI.  (David Steele <david@pgmasters.net>)
Responses Re: Don't try fetching future segment of a TLI.
Re: Don't try fetching future segment of a TLI.
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Internal key management system
Next
From: Daniel Gustafsson
Date:
Subject: Re: Add FOREIGN to ALTER TABLE in pg_dump