Hi, On Tue, Jun 23, 2009 at 1:55 AM, Markus Wanner<mar...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
