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

From: Pavel Suderevsky <psuderevsky(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Don't try fetching future segment of a TLI.
Date: 2020-03-19 13:22:16
Message-ID: CAEBTBzupObE6Gep1y-ajvUh4AjuvyTmfTewshVOei12uRV=Q8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs 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(at)pgmasters(dot)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(at)pgmasters(dot)net
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-03-19 13:33:36 Re: BUG #16302: too many range table entries - when count partition table(65538 childs)
Previous Message Demarest, Jamie 2020-03-19 12:48:12 RE: Postgresql create a core while trying log a message to syslog

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-03-19 13:29:42 Re: Add FOREIGN to ALTER TABLE in pg_dump
Previous Message Bruce Momjian 2020-03-19 13:00:54 Re: Internal key management system