Re: Fix spinlock usage in UnpinBuffer()

> 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