I’ve been reading some old papers about locking and MVCC in preparation for writing about MVCC in PostgreSQL, and for giving a talk at CouchCamp next week!
I just finished “Locking“, by Jim Gray. He discusses semaphores, and makes the argument for implementing a locking scheduler to handle errors and deadlocks (which he calls interlocks, or a “deadly embrace” – a term I’m sad we’ve stopped using).
An example from the start of the paper illustrates the power of MVCC:
The classic example is an accounting file. Processes reading the file may share it
concurrently. However, a process requesting write access to the file blocks until all processes currently reading have released the file.
A lovely thing about Postgres’ MVCC is that readers (SELECT) don’t require this type of lock, and most writers don’t block readers. For SELECT, the only statements that will block it are those that make changes to tables which move all rows physically around (VACUUM FULL, CLUSTER, REINDEX, TRUNCATE), or make changes to table structure (ALTER TABLE, DROP TABLE).
Have a look at the explicit locking docs for more detail on the lock modes automatically used by PostgreSQL.
I love how that PDF is a scan of a paper written with a monospace font.
There’s been a real effort in the python community in the last year or so to tear down the barriers to entry on python core development.
PostgreSQL is my favorite tool — but I’m deeply intimidated by the idea of hacking on it.
Matt:
Thanks for the note! I liked that there were hand-written corrections as well 🙂
If you find something you want to hack on inside Postgres, lemme know. I think the most scary part about sending patches in has to do with the review process.. But we’ve put a lot of effort (with our commitfest process) into getting more people involved, and making it all around less painful than it used to be.