Re: Back-patch is necessary? Re: Don't try fetching future segment of a TLI.

On Thu, Apr 30, 2020 at 7:46 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>
> On 2020/04/08 1:49, Fujii Masao wrote:
> >
> >
> > On 2020/04/07 20:21, David Steele wrote:
> >>
> >> On 4/7/20 3:48 AM, Kyotaro Horiguchi wrote:
> >>> At Tue, 7 Apr 2020 12:15:00 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
> >>>>>> This doesn't seem a bug, so I'm thinking to merge this to next *major*
> >>>>>> version release, i.e., v13.
> >>>>> Not a bug, perhaps, but I think we do consider back-patching
> >>>>> performance problems. The rise in S3 usage has just exposed how poorly
> >>>>> this performed code in high-latency environments.
> >>>>
> >>>> 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?
> >>>
> >>> +1 for commit only v13 today, then back-patch if people wants and/or
> >>> accepts.
>
> Please let me revisit this. Currently Grigory Smolkin, David Steele,
> Michael Paquier and Pavel Suderevsky agree to the back-patch and
> there has been no objection to that. So we should do the back-patch?
> Or does anyone object to that?
>
> I don't think that this is a feature bug because archive recovery works
> fine from a functional perspective without this commit. OTOH,
> I understand that, without the commit, there is complaint about that
> archive recovery may be slow unnecessarily when archival storage is
> located in remote, e.g., Amazon S3 and it takes a long time to fetch
> the non-existent archive WAL file. So I'm ok to the back-patch unless
> there is no strong objection to that.
>

I don't see any obvious problem with the changed code but we normally
don't backpatch performance improvements. I can see that the code
change here appears to be straight forward so it might be fine to
backpatch this. Have we seen similar reports earlier as well? AFAIK,
this functionality is for a long time and if people were facing this
on a regular basis then we would have seen such reports multiple
times. I mean to say if the chances of this hitting are less then we
can even choose not to backpatch this.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com