Re: Standby trying "restore_command" before local WAL

> There's still a question here, at least from my perspective, as to which
> is actually going to be faster to perform recovery based off of.  A good
> restore command, which pre-fetches the WAL in parallel and gets it local
> and on the same filesystem, meaning that the restore_command only has to
> execute essentially a 'mv' and return back to PG for the next WAL file,
> is really rather fast, compared to streaming that same data over the
> network with a single TCP connection to the primary.  Of course, there's
> a lot of variables there and it depends on the network speed between the
> various pieces, but I've certainly had cases where a replica catches up
> much faster using restore command than streaming from the primary.

Trying "restore_command" before streaming replication is totally fine.
It is not likely that the same WAL would be on both places anyway.

My problem is trying "restore_command" before the local WAL.  I
understand the historic reason of this design, but I don't think it is
expected behavior to anybody who is using "restore_command" together
with streaming replication.

Of course speeding up "restore_command" is a good thing to do
independently.  Thank you for working on this.