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.fu...@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.
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.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
