On Fri, Sep 3, 2010 at 4:20 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Maybe that's ok, if I'm reading the deadlock checker code correctly, it also > calls semop() to increment the another process' semaphore, and the deadlock > checker can be invoked from a signal handler while in semop() to wait on our > process' semaphore. BTW, sem_post(), which is the Posix function for > incrementing a semaphore, is listed as a safe function to call in a signal > handler. But it's certainly fishy.
Color me confused; I may need to backpedal rapidly here. I had thought that what Tom was complaining about was the fact that the signal handler was taking LWLocks, which I would have thought to be totally unsafe. But it seems the deadlock detector does the same thing, more or less because the signal handlers are set up so that they don't do anything unless we're within a limited section of code where nothing too interesting can happen. I'm not too sure why we think that it's safe to invoke the deadlock detector that way, but it's also not too clear to me why this case is any worse. It furthermore appears that Simon's reply to Tom's complaint about this function was: "This was modelled very closely on handle_sig_alarm() and was reviewed by other hackers. I'm not great on that, as you know, so if you can explain what it is I can't do, and how that differs from handle_sig_alarm running the deadlock detector in the same way, then I'll work on it some more." I guess I need the same explanation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
