Hi, Fujii Masao wrote: > The perfect solution seems to be to remove SA_RESTART and handle EINTR > in an appropriate way after every syscalls. But, this is very tough job and > has > much influence on whole source code, so I don't think that this should be done > as part of synch rep.
Especially note Tom's valid concerns about third party code. OTOH checking against error codes should be common practice. And the failure can then clearly be located in the third party module, and not in Postgres. > 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? 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. Just my 2c. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
