Re: Switching XLog source from archive to streaming when primary available
Cary Huang <cary.huang@highgo.ca>
From: Cary Huang <cary.huang@highgo.ca>
To: pgsql-hackers@lists.postgresql.org
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: 2022-06-24T20:00:38Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add basic TAP tests for the low-level backup method, take two
- 071e3ad59d6f 17.0 cited
-
Add a failover option to subscriptions.
- 776621a5e479 17.0 cited
-
Make all Perl warnings fatal
- c5385929593d 17.0 cited
-
Add PostgreSQL::Test::Cluster::advance_wal
- c161ab74f76a 17.0 cited
-
Rename wal_keep_segments to wal_keep_size.
- c3fe108c025e 14.0 cited
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. thank you Cary Huang HighGo Software Canada