Hi,
On Wed, Dec 24, 2008 at 5:48 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> On Wed, Dec 24, 2008 at 1:50 PM, Fujii Masao <masao.fujii@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