Hi, Simon Riggs wrote:
The standby server won't come up until you have: * copied the base backup * sent it to standby server * bring up standby, have it realise it is a replication partner and begin requesting WAL from primary (in some way)
Right. That was your assumption as well. Required before step 1 in both cases.
If we start caching WAL right away we would need to have two receivers. One to receive the missing WAL data and one to receive the current WAL data. We can't apply the WAL until we have the earlier missing WAL data, so cacheing it seems difficult.
You could use the same receiver process and just handle different packets differently. I see no need for two separate receiver processes here.
On a large server this might be GBs of data.
..if served from a log archive, correct. Without archiving, we are limited to xlog anyway.
Seems easier to not cache current WAL and to have just a single WALReceiver process that performs a mode change once it has caught up. (And I should say "if it catches up", since it is possible that it never actually will catch up, in practical terms, since this depends upon the relative power of the servers involved.). So there's no need to store more WAL on standby than is required to restart recovery from last restartpoint. i.e. we stream WAL at all times, not just in normal running mode.
Switching between streaming from files and 'live' streaming on the active node seems difficult to me, because you need to make sure there's no gap. That problem could be circumvented by handling this on the standby. If you think switching on the active is simple enough, that's fine.
Seems easiest to have: * Startup process only reads next WAL record when the ReceivedLogPtr > ReadRecPtr, so it knows nothing of how WAL is received. Startup process reads directly from WAL files in *all* cases. ReceivedLogPtr is in shared memory and accessed via spinlock. Startup process only ever reads this pointer. (Notice that Startup process is modeless).
Well, that's certainly easier for the standby, but requires mode switching on the active.
Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
