Hi, On Wed, Dec 24, 2008 at 5:48 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > On Wed, Dec 24, 2008 at 1:50 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >> >> >> And, I'm worried about the situation that the speed to generate xlog >> on the primary is higher than that to copy them to the standby. We >> might not be able to start xlog streaming forever. >> > > If that's the case, how do you expect the standby to keep pace with > the primary after initial sync up ?
Good question. If streaming and copying are performed parallelly, such situation doesn't happen because the speed to generate xlog also depends on streaming. This is a price to pay. I think that the serial operations would need a "pace maker". And, I don't know better pace maker than concurrent streaming. > Frankly, I myself have every doubt > that on a relatively high load setup, the standby will not be able > keep pace with the primary for two reasons: > > - Lack of read ahead of data blocks (Suzuki-san's work may help this) > - Single threaded recovery > > But then these are general problems which may impact any log-based > replication. Right. Completely high load setup is probably impossible. There is certainly a price to pay. But, in order to reduce a price as much as possible, I think that we should not focus two or more operations on single process (walsender) just like single threaded recovery. 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
