Hi,
Tom Lane <t...@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 all to 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 applies from 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 or not 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
