| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synch Rep v5 |
| Date: | 2009-01-11 16:16:42 |
| Message-ID: | 1231690602.18005.890.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-01-11 16:35:33 | Recovery Test Framework |
| Previous Message | Simon Riggs | 2009-01-11 16:10:07 | Re: Synch Rep v5 |