On Tue, Dec 27, 2022 at 02:45:30PM -0800, Andres Freund wrote:
> On 2022-12-27 14:37:11 -0800, Nathan Bossart wrote:
>> On Tue, Dec 27, 2022 at 02:11:11PM -0800, Andres Freund wrote:
>> > On 2022-12-27 11:24:49 -0800, Nathan Bossart wrote:
>> >> * pg_rewind uses restore_command, but there isn't a straightforward path to
>> >> support restore_library. I haven't addressed this in the attached patches,
>> >> but perhaps this is a reason to allow specifying both restore_command and
>> >> restore_library at the same time. pg_rewind would use restore_command, and
>> >> the server would use restore_library.
>> >
>> > That seems problematic, leading to situations where one might not be able to
>> > use restore_command anymore, because it's not feasible to do
>> > segment-by-segment restoration.
>>
>> I'm not following why this would make segment-by-segment restoration
>> infeasible. Would you mind elaborating?
>
> Latency effects for example can make it infeasible to do segment-by-segment
> restoration infeasible performance wise. On the most extreme end, imagine WAL
> archived to tape or such.
I'm sorry, I'm still lost here. Wouldn't restoration via library tend to
improve latency? Is your point that clusters may end up depending on this
improvement so much that a shell command would no longer be able to keep
up? I might be creating a straw man, but this seems like less of a concern
for pg_rewind since it isn't meant for continuous, ongoing restoration.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com