Hi,
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I think this fails the basic sanity check: do you need it to still work
> when the master is dead.
I don't get it. Why would we want to setup a slave against a dead
master?
The way I understand the current design of Synch Rep, when you start a
new slave the following happen:
1. init: slave asks the master the current LSN and start streaming WAL
2. setup: slave asks the master for missing WALs from its current position to this LSN it just got, and apply them
allto reach initial LSN (this happen in parallel to 1.)
3. catchup: slave has replayed missing WALs and now is replaying the stream he received in parallel, and which
appliesfrom init LSN (just reached)
4. sync: slave is no more lagging, it's applying the stream as it gets it, either as part of the master transaction
ornot depending on the GUC settings
So, what I'm understanding you're saying is that the slave still should
be able to setup properly when master died before it synced. What I'm
saying is that if master dies before any sync slave exists, you get to
start from backups (filesystem snaphost + archives for example, PITR
recovery etc), as there's no slave.
Regards,
--
dim