Hi, Thanks for clarifying!
On Wed, Dec 24, 2008 at 2:53 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Tue, 2008-12-23 at 18:23 +0200, Heikki Linnakangas wrote: > >> I don't think we need or should >> allow running regular queries before entering "replication mode". the >> backend should become a walsender process directly after authentication. > > +1 OK, I will re-examine it. But, at least, we need to send ReadyForQuery message after authentication before sending WAL, because walreceiver uses libpq (PQsetdbLogin), which doesn't return until receiving ReadyForQuery. > >> Standby -> primary >> >> RequestWAL <begin> <end> >> Primary should respond with a WALRange message containing the given >> range of WAL data. >> >> StartReplication <begin> >> Primary should send all already-generated WAL beginning from <begin>, >> and then keep sending as it's generated. > > Can you give a quick example of how these would be used? > > Fujii-san and others considered that having replication start early was > an important requirement. If we do these operations serially on the same > connection > * copy all bulk data > * start streaming > then there is a considerable delay before replication can begin. In the > case of some large sites, perhaps as long as 18-24 hrs. Agreed. In very busy system, if those operations are performed serially, we might not be able to start streaming. I mean that the speed to generate WAL might be higher than that to copy them. > >> ReplicatedUpTo <end> >> Acknowledge that all WAL up to <end> has been successfully received and >> written to disk and/or fsync'd (depending on the replication mode in >> use). The primary can use this information to acknowledge a transaction >> as committed to the client in case of synchronous replication. > > +1 Yes. > >> Primary -> standby >> >> WALRange <begin> <end> <data> >> Response to RequestWAL or StartReplication message. After receiving a >> StartReplication message, the primary can send these messages when it >> feels like it. In synchronous mode, that would be at least at each >> commit. The standby should respond with a ReplicatedUpTo message to each >> WALRange message. > > +1 Currently, <begin> is not sent because it can be calculated from <end> and data length. This would decrease a network traffic in some degree. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers