Re: Switching XLog source from archive to streaming when primary available
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Cary Huang <cary.huang@highgo.ca>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: 2023-01-12T00:51:14Z
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
On Tue, Oct 18, 2022 at 07:31:33AM +0530, Bharath Rupireddy wrote: > In summary, the standby state machine in WaitForWALToBecomeAvailable() > exhausts all the WAL in pg_wal before switching to streaming after > failing to fetch from archive. The v8 patch proposed upthread deviates > from this behaviour. Hence, attaching v9 patch that keeps the > behaviour as-is, that means, the standby exhausts all the WAL in > pg_wal before switching to streaming after fetching WAL from archive > for at least streaming_replication_retry_interval milliseconds. I think this is okay. The following comment explains why archives are preferred over existing files in pg_wal: * When doing archive recovery, we always prefer an archived log file even * if a file of the same name exists in XLOGDIR. The reason is that the * file in XLOGDIR could be an old, un-filled or partly-filled version * that was copied and restored as part of backing up $PGDATA. With your patch, we might replay one of these "old" files in pg_wal instead of the complete version of the file from the archives, but I think that is still correct. We'll just replay whatever exists in pg_wal (which may be un-filled or partly-filled) before attempting streaming. If that fails, we'll go back to trying the archives again. Would you mind testing this scenario? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com