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
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 |