Re: Synch Rep v5

Hi,

On Mon, Jan 12, 2009 at 1:16 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Sun, 2009-01-11 at 15:11 +0900, Fujii Masao wrote:
>
>> Yes, using semaphores for the communication is also my first approach.
>> The problem of this approach is that walsender cannot wait for both
>> signal from backends and the response from walreceiver concurrently,
>> because
>> wait-for-semaphore is blocking at least. So, I use signal for the
>> communication.
>
> IIUC: In sync mode backend sends signal to walsender, then adds itself
> to wait queue on semaphore. walsender responds to signal, sends more WAL
> then waits for response. When response comes it then wakes backends on
> the semaphore. In async mode, no signal is sent and we do not wait, we
> just allow the walsender to wake up periodically and send.

I'd like walsender not to wait for response in blocking mode. Because, if so,
the network delay would directly interfere with transaction processing. In
my design, walsender waits for response in non-blocking mode and tries to
send the next requested WAL if any responses have not arrived yet. So,
walsender needs to wait for signal from backend and response from standby
concurrently.

Problem is how walsender should wait for signal and response concurrently.
If we use select/poll for it, walsender cannot respond the signal immediately
in some platform. If we don't use them (which means the loop without sleep),
CPU utilization would jump.

> Does it release waiters as soon as possible, or does it always respond
> to new requests for sending? i.e. which has priority - responding to
> waiters who need to be woken or responding to new requests to send?

Responding to waiters should have higher priority, for stability of response
time. In fact, if both the signal from backend and the response from the
standby have arrived, walsender reads the response and wakes the waiters
up in first.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center