Tim Conrad wrote:
> > MySQL uses traditional row-level locking. PostgreSQL uses something
> > called Multi Version Concurrency Control (MVCC) by default. MVCC is
a
> > little different from row-level locking in that transactions on the
> > database are performed on a snapshot of the data and then
serialized.
> > New versions of PostgreSQL support standard row-level locking as an
> > option, but MVCC is the preferred method.
> > --------
> Nice that you point out that incorrectly stated something. Even
> nicer that you don't tell me what the correct answer would be.
> Unfortunanatly, that's the best I could come up with with doing
> research with the documentation I could find on the subject. MVCC
> does a lot more than can be easily contained in a sentance.
For the record:
PostgreSQL currently has row level locking: locks are acquired by
writing to the data and released by committing/rolling back a
transaction. What makes this different from traditional 'library book
model' locking systems is that writers do not block writers, only other
readers. Basically, the server has a very clever way about managing row
locks between multiple users...hence the designation 'better than row
locking' (read: better than traditional row locking).
What could conceivably be offered as a feature is to allow locks outside
of a transaction which is currently now allowed (and many people will
tell you is a bad idea).
I just read your article and honestly I thought it was all right; you
hit a lot of the important things about Postgres (mentioning the .org
domain was a nice plug). Some people here are understandably a little
touchy about the FUD that mysql has been spreading (they had a chapter
in their manual about why *not* to use postgresql.
To the serious application developer (at leaste to me), the features
that PostgreSQL are integral to good application development.
Merlin
p.s. if you would like to test/use the windows port I can send along
instructions about how to do it...it involves compiling :).
