Re: Deadlock Detected (revisited)

From: Wes <wespvp(at)syntegra(dot)com>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Deadlock Detected (revisited)
Date: 2005-11-26 02:52:59
Message-ID: BFAD2A2B.6DAC%wespvp@syntegra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 11/25/05 2:40 AM, "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com> 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?

Wes

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2005-11-26 03:12:21 Re: Deadlock Detected (revisited)
Previous Message Michael Fuhr 2005-11-26 02:36:38 Re: Function name variable within a non-trigger function