> 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.
