How 3.6 nearly broke PostgreSQL

Posted Oct 3, 2012 3:19 UTC (Wed) by josh (subscriber, #17465)
In reply to: How 3.6 nearly broke PostgreSQL by fdr
Parent article: How 3.6 nearly broke PostgreSQL

How much faster is PostgreSQL's userspace locking than futexes? In theory, futexes have no kernel overhead when acquired uncontended, and minimal overhead (just the overhead of blocking in the scheduler) when contended. The only case I can think of that would have less overhead would involve busy-waiting in userspace.

How 3.6 nearly broke PostgreSQL

Posted Oct 3, 2012 4:30 UTC (Wed) by fdr (guest, #57064) [Link]

I think someone wrote up a prototype (actually, I think that may be several across many years, this being the latest incarnation I know of):

http://archives.postgresql.org/pgsql-hackers/2012-06/msg0...

This actually uses futexes indirectly, in my understanding from the post, and it's not the most awful thing for Linux.

It's possible that Linux futexes are not a bad idea (but it's also not clearly a huge improvement), but s_lock does okay and has existed an awfully long time (with iteration), so there's some inertia there.

Also, I think I oversimplified the parent's post, he could have simply meant that something about s_lock is not very good, as opposed to "self-rolled user space spinlocks? That's ridiculous!" (as a straw man). It's possible s_lock could be improved, however, it was fine before and doesn't clearly seem at fault right now. I think the suggestion of having to manhandle the platform-specific scheduler also seems excessive. There may be a better solution to serve everyone; somehow I can't see PostgreSQL's spinlocks being one-of-a-kind in this pathology, but I haven't attempted to prove that.