Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Greg Smith <greg@2ndquadrant.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org
Date: 2010-08-20T14:15:47Z
Lists: pgsql-hackers
On 20/08/10 16:24, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@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. If we have to, we could also support multiple interrupts with multiple self-pipes, so that you can choose at pg_usleep() which ones to wake up on. >> 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 :-(. Well yes, the other places where we use pg_usleep() are not really a problem as is. If as a side-effect we can make them respond more quickly to signals, with small changes, that's good, but walsender is the only one that's performance critical. That said, a select() based solution is my current favorite. > 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. There's semtimedop(). I don't know how portable it is, but it seems to exist at least on Linux, Solaris, HPUX and AIX. On what platforms do we use sysv semaphores? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com