On Fri, 25 Nov 2005, Wes wrote: > On 11/25/05 2:40 AM, "Stephan Szabo" <sszabo@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > 8.1 should be using the new shared row locks for doing the checks. This > > should fix the case mentioned. > > Hmm. I'm looking in the "What's new" for 8.1 and see that now. I could > have sworn it wasn't there the last time I looked. Sorry. > > > Up until now, we didn't have one to get on a per-record basis. > > Ok, I guess I'm confused... From the 7.3.2 manual (6.5 updates): > > "Multiversion concurrency control(MVCC) This removes our old table-level > locking, and replaces it with a locking system that is superior to most > commercial database systems. In a traditional system, each row that is > modified is locked until committed, preventing reads by other users. MVCC > uses the natural multiversion nature of PostgreSQL to allow readers to > continue reading consistent data during writer activity. Writers continue to > use the compact pg_log transaction system. This is all performed without > having to allocate a lock for every row like traditional database systems. > So, basically, we no longer are restricted by simple table-level locking; we > have something better than row-level locking." > > So, until 8.1 PostgreSQL had "something better than row-level locking" for > some things, but no row locking when needed? Or was it row locking is > there, but just no shared row locking? The latter, the row locks before were single owner and were such that a second lock request for the same row would wait for the first to be released. Now effectively you have two levels of locks at the row level, the weaker of which conflicts with the stronger but not with itself. The thing about MVCC is that readers do not have to get either lock if they aren't trying to prevent modifications.
