Hi,
On Sat, Jan 10, 2009 at 10:42 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Sat, 2009-01-10 at 19:16 +0900, Fujii Masao wrote:
>
>> On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> >> 4. sleeping
>> >> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00438.php
>> >>
>> >> I'm looking for the better idea. How should we resolve that problem?
>> >> Only reduce the timeout of pq_wait to 100ms? Get rid of
>> >> SA_RESTART only during pq_wait as follows?
>> >>
>> >> remove SA_RESTART
>> >> pq_wait()
>> >> add SA_RESTART
>> >
>> > Not sure, will consider. Ask others as well.
>>
>> I've not got an idea yet. Now (v5), I only reduce the timeout of
>> pq_wait to 100ms. Is this sufficient? Do you have any good idea?
>
> To be honest I didn't follow that part of the discussion.
>
> My preferred approach, mentioned earlier in the summer, was to use a
> mechanism very similar to LWlocks. A proc queue with semaphores. Minimum
> delay, no need for signals. The process doing the wakeup can walk up the
> queue until it finds somebody whose wait-for-LSN is higher than has just
> been sent/written. Doing it this way also gives us group commit when
> synch rep is not enabled.
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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center