Re: Locking that will delayed a SELECT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ludwig Lim <lud_nowhere_man(at)yahoo(dot)com>
Cc: PostgreSQL Mailing List <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Locking that will delayed a SELECT
Date: 2002-10-18 18:03:12
Message-ID: 19055.1034964192@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Ludwig Lim <lud_nowhere_man(at)yahoo(dot)com> writes:
> *** For clarification ***

> In the SQL command reference of PostgreSQL:
> in SELECT statement section :
> "The FOR UPDATE clause allows the SELECT
> statement to perform exclusive locking of selected
> rows"

Hmm. That is a misstatement: FOR UPDATE only locks the selected row(s)
against other updates (ie UPDATE, DELETE, SELECT FOR UPDATE), so it's
not "exclusive" in the usual sense of the word: readers can still see
the row. I'll fix that for 7.3, but meanwhile you might care to read
the 7.3 development docs' discussion of concurrency, which is (IMHO
anyway) more accurate than what was there before:

http://developer.postgresql.org/docs/postgres/mvcc.html

Note in particular that table-level locks and row-level locks are two
independent features. Updates acquire an appropriate table-level lock
and then acquire row locks on the rows they are updating.

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Stephan Szabo 2002-10-18 18:18:22 Re: [SQL] foreign key, create table, and transactions
Previous Message Bruce Momjian 2002-10-18 18:02:43 Re: triggers