Re: Re[4]: Allowing WAL fsync to be done via O_SYNC

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as long as you never block, but it sucks for making things
> wait, because the wait interval will be some multiple of 10 msec rather
> than just the time till the lock comes free.

Plus, using select() for the timeout is putting you into the kernel
multiple times in a short period, and causing a reschedule everytime,
which is a big lose. This was discussed in the linux-kernel thread
that was referred to a few days ago.

> We've speculated about using Posix semaphores instead, on platforms
> where those are available. I think Bruce was concerned about the
> possible overhead of pulling in a whole thread-support library just to
> get semaphores, however.

Are Posix semaphores faster by definition than SysV semaphores (which
are described as "slow" in the source comments)? I can't see how
they'd be much faster unless locking/unlocking an uncontended
semaphore avoids a system call, in which case you might run into the
same problems with userland backoff...

Just looked, and on Linux pthreads and POSIX semaphores are both
already in the C library. Unfortunately, the Linux C library doesn't
support the PROCESS_SHARED attribute for either pthreads mutexes or
POSIX semaphores. Grumble. What's the point then?

Just some ignorant ramblings, thanks for listening...

-Doug