Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > Hmm, we have pg_usleep() calls in some fairly low-level functions, like > mdunlink() and s_lock(). If someone has called SetSleepInterrupt(), we > don't want those pg_usleep()s to return immediately. And pg_usleep() is > used in some client code too. I think we need a separate sleep function > for this.
Well, we'd need some careful thought about which sleeps need what, but I don't necessarily have an objection to a separate interruptable sleep function. > Another idea is to not use unix signals at all, but ProcSendSignal() and > ProcWaitForSignal(). We would not need the signal handler at all. > Walsender would use ProcWaitForSignal() instead of pg_usleep() and > backends that want to wake it up would use ProcSendSignal(). You keep on proposing solutions that only work for walsender :-(. Most of the other places where we have pg_usleep actually do want a timed sleep, I believe. It's also unclear that we can always expect ProcSendSignal to be usable --- for example, stuff like SIGHUP would be sent by processes that might not be connected to shared memory. > The problem > is that there is currently no way to specify a timeout, but I presume > the underlying semaphore operations have that capability, and we could > expose it. They don't, or at least the semop-based implementation doesn't. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers