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

On 2020/05/02 20:40, Amit Kapila wrote:
> 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.

I found the following two reports. ISTM there are not so many reports...
https://www.postgresql.org/message-id/16159-f5a34a3a04dc67e0@postgresql.org
https://www.postgresql.org/message-id/dd6690b0-ec03-6b3c-6fac-c963f91f87a7%40postgrespro.ru

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION