Re: Row Locking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: aklayman(at)mindspring(dot)com
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Row Locking
Date: 2002-05-20 14:24:06
Message-ID: 22303.1021904646@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alexander Klayman <aklayman(at)mindspring(dot)com> writes:
> LOCK TABLE A IN ROW EXCLUSIVE MODE;
> SELECT c FROM A WHERE id=1; # The row with d=1 is locked

You seem to have a fundamental misconception about what sort of locking
Postgres does.

LOCK TABLE gets table-level locks of various kinds. The names for the
lock types are fairly bizarre and unhelpful IMHO, but they are all
*table* level, without exception; and there is no change in the behavior
of other statements.

The only sorts of row-level locks we use are those acquired by
updating/deleting an existing row, or equivalently by SELECT FOR UPDATE
(which doesn't change the row, but marks it as if it did). These
locks do not prevent another transaction from reading the row with
SELECT --- only from updating, deleting, or selecting it FOR UPDATE.

All locks are held till transaction commit.

regards, tom lane

In response to

  • Row Locking at 2002-05-20 03:53:23 from Alexander Klayman

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-05-20 14:48:21 Re: PostgreSQL 7.1 forces sequence scan when there is no reason
Previous Message Joel Burton 2002-05-20 13:58:53 Re: Further thoughts on Referential Integrity