On Wed, 2008-09-10 at 17:57 +0900, Fujii Masao wrote: > My sequence covers several cases : > > * There is no missing WAL file. > * There is a lot of missing WAL file.
This is the likely case for any medium+ sized database. > * There are missing history files. Failover always generates the gap > of > history file because TLI is incremented when archive recovery is > completed. Yes, but failover doesn't happen while we are configuring replication, it can only happen after we have configured replication. It would be theoretically possible to take a copy from one server and then try to synchronise with a 3rd copy of the same server, but that seems perverse and bug prone. So I advise that we only allow replication when the timeline of the standby matches the timeline of the master, having it as an explicit check. > In your design, does not initial setup block the master? > Does your design cover above-mentioned case? The way I described it does not block the master. It does defer the point at which we can start using synchronous replication, so perhaps that is your objection. I think it is acceptable: good food takes time to cook. I have thought about the approach you've outlined, though it seems to me now like a performance optimisation rather than something we must have. IMHO it will be confusing to be transferring both old and new data at the same time from master to slave. We will have two different processes sending and two different processes receiving. You'll need to work through about four times as many failure modes, all of which will need testing. Diagnosing problems in it via the log hurts my head just thinking about it. ISTM that will severely impact the initial robustness of the software for this feature. Perhaps in time it is the right way. Anyway, feels like we're getting close to some good designs. There isn't much difference between what we're discussing here. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers