Re: Standby trying "restore_command" before local WAL - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: Standby trying "restore_command" before local WAL
Date
Msg-id CAE2gYzwny7jzB+xqdY=3o8EJnK16ycF8Jy2x+83EX7d6DYBr=g@mail.gmail.com
Whole thread Raw
In response to Re: Standby trying "restore_command" before local WAL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Standby trying "restore_command" before local WAL
List pgsql-hackers
> 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.


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: [Patch] Checksums for SLRU files
Next
From: Fabien COELHO
Date:
Subject: Re: Doc patch: add RECURSIVE to bookindex