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

From Fujii Masao
Subject Re: Don't try fetching future segment of a TLI.
Date
Msg-id 21d2590f-2739-9f45-748f-7a68d667d7cd@oss.nttdata.com
Whole thread Raw
In response to Re: Don't try fetching future segment of a TLI.  (David Steele <david@pgmasters.net>)
Responses Back-patch is necessary? Re: Don't try fetching future segment of aTLI.
Back-patch is necessary? Re: Don't try fetching future segment of aTLI.
List pgsql-hackers

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.fujii@oss.nttdata.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.
> 
> Definitely +1 for a commit today to v13. I certainly was not trying to hold that up
Pushed the patch to v13, at first!

Regards,

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Generate backup manifests for base backups, and validate them.
Next
From: Jeevan Chalke
Date:
Subject: Re: WIP/PoC for parallel backup