Here—have a microbenchmark!

Here are two really simple mutexes: a wrapper around the pthread functions, and a no-thought-required spinlock:

    class Spinlock {
    private:
        bool state;
    public:
        Spinlock() { state = false; }
        void lock() {
            while(!__sync_bool_compare_and_swap(&state, false, true));
        }
        void unlock() {
            state = false;
            __sync_synchronize();
        }
    };
    
    class PthreadMutex {
    private:
        pthread_mutex_t mutex;
    public:
        PthreadMutex() {
            pthread_mutex_init(&mutex, NULL);
        }
        void lock() {
            pthread_mutex_lock(&mutex);
        }
        void unlock() {
            pthread_mutex_unlock(&mutex);
        }
        ~PthreadMutex() {
            pthread_mutex_destroy(&mutex);
        }
    };

I used these to protect a not-optimized-at-all dispatch queue built on top of std::deque (single reader, single writer, reader busy-waits until work is available, work is an empty function). I did this test on Mac OS X 10.6.8 (with Apple s gcc 4.2.1 build).

A run using PthreadMutex:

    0,5944405
    1,1627173
    2,135598
    3,363801
    4,3360217
    5,5773374
    6,5727638
    7,5953505
    8,4567648
    9,5106300

Using Spinlock:

    0,154817
    1,187507
    2,145171
    3,102454
    4,180604
    5,155360
    6,128448
    7,82418
    8,49538
    9,39560

All times are in microseconds to run 1,000,000 iterations of the test. Only time to enqueue is measured.

I've seen similar results with a very similar test on FreeBSD, though I don't have a box to retest on at the moment.

I can only conclude it's not at all unreasonable for PostgreSQL to use its own spinlocks.