> So can you drop several lines on last post in list? [ looks at code some more... ] Actually, I think this code thinks that RESUME_INTERRUPTS() will do a CHECK_FOR_INTERRUPTS() if the count drops to zero. Which it does not. (Perhaps it did at one time --- I don't recall for sure --- but it definitely doesn't now.)
Realistically, given our coding rules for spinlocks --- which pretty nearly forbid *any* out-of-line calls while holding a spinlock, and certainly forbid any looping --- it's probably a waste of cycles to have the HOLD/RESUME_INTERRUPTS operations associated with spinlock grab/release at all. There is simply no way that any legitimate path of control will do a CHECK_FOR_INTERRUPTS() while holding or awaiting a spinlock. So I'm thinking the right answer is to make all the spinlock macros be the equivalent of the NoHoldoff case. It's reasonable for LWLockAcquire to do a HOLD_INTERRUPTS, but I don't see the justification for doing it at the spinlock level. > Another thing is the qsort(). Shall we change to BSD version or just let > it be? I'm a bit worried about doing that across-the-board, since at least in theory a vendor-supplied qsort ought to be tuned for the hardware et al. I think it would be better to substitute our own qsort only on those platforms where we have specifically proved it's a win. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq