Hi,
On Tue, Jun 23, 2009 at 1:55 AM, Markus Wanner<markus@bluegap.ch> wrote:
>> On the other hand, I think that a semaphore should be used instead of a signal
>> at least for backends to wait for walsender. This would turn around
>> the situation
>> on HPUX in some degree. In this case, the remaining problem is that walsender
>> cannot immediately wake up. But, since walsender wakes up periodically and
>> that period can be tweaked (by new GUC wal_sender_delay), the overhead on
>> HPUX might not be actually so big.
>
> Hm.. does the walsender really wake up periodically? IIRC the
> misbehavior discovered on HPUX is that select() gets restarted upon
> signaled with SA_RESTART - with its full timeout, so that a steady rate
> of signals would lock the walsender process within select() completely.
> Or what else do you use for the walsender to wake up periodically?
I was thinking of reducing the number of signals by backends using
the shared flag which indicates whether walsender has already received
it or not. If the flag is true, the backend skips sending the signal because
walsender is going to wake up soon. Otherwise, the signal is sent, then
the signal handler of walsender sets the flag to true. Though I need to
examine it furthermore.
> However, my point is that I think you don't have to solve this problem.
> It should rather be taken care of by core. We can then pick up whatever
> solution is decided on.
Good for me. Does anyone have another thought? If not, I would
remove this task from the TODO list of synch rep.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center