Re: Don't try fetching future segment of a TLI.
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: David Steele <david@pgmasters.net>, Pavel Suderevsky <psuderevsky@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org, pgsql-bugs@lists.postgresql.org
Date: 2020-04-07T08:17:32Z
Lists: pgsql-bugs, pgsql-hackers
On Tue, Apr 07, 2020 at 12:15:00PM +0900, Fujii Masao wrote: > 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? I have not looked at the patch so I cannot say much about it, but it is annoying to fetch segments you are not going to need anyway if you target recovery with a timeline older than the segments fetched and this has a cost when you pay for the bandwidth of your environment with only one archive location. So a backpatch sounds like a good thing to do even if recovery is not broken per-se, only slower. Designing a TAP test for that is tricky, but you could look at the logs of the backend to make sure that only the wanted segments are fetched with a central archived solution and multiple timelines involved. And costly it is. -- Michael
Commits
-
Prevent archive recovery from scanning non-existent WAL files.
- e3f5b148ed32 9.5.22 landed
- 70b5979742f8 9.6.18 landed
- 660f1fc40d7a 10.13 landed
- dcd1569fb05d 11.8 landed
- 683e0ef5530f 12.3 landed
- 4bd0ad9e44be 13.0 landed