On Sat, Jun 25, 2022 at 1:31 AM Cary Huang <cary.hu...@highgo.ca> wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested > Documentation: not tested > > Hello > > I tested this patch in a setup where the standby is in the middle of > replicating and REDOing primary's WAL files during a very large data > insertion. During this time, I keep killing the walreceiver process to cause > a stream failure and force standby to read from archive. The system will > restore from archive for "wal_retrieve_retry_interval" seconds before it > attempts to steam again. Without this patch, once the streaming is > interrupted, it keeps reading from archive until standby reaches the same > consistent state of primary and then it will switch back to streaming again. > So it seems that the patch does the job as described and does bring some > benefit during a very large REDO job where it will try to re-stream after > restoring some WALs from archive to speed up this "catch up" process. But if > the recovery job is not a large one, PG is already switching back to > streaming once it hits consistent state.
Thanks a lot Cary for testing the patch. > Here's a v1 patch that I've come up with. I'm right now using the > existing GUC wal_retrieve_retry_interval to switch to stream mode from > archive mode as opposed to switching only after the failure to get WAL > from archive mode. If okay with the approach, I can add tests, change > the docs and add a new GUC to control this behaviour. I'm open to > thoughts and ideas here. It will be great if I can hear some thoughts on the above points (as posted upthread). Regards, Bharath Rupireddy.
