From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Table vs. row level locks confusion |
Date: | 2001-09-04 15:01:08 |
Message-ID: | 26359.999615668@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The following section
> http://www.ca.postgresql.org/devel-corner/docs/postgres/locking-tables.html
> titled "Locking and Tables", has two subsections, "Table-level locks" and
> "Row-level locks". Under table-level locks we find lock names such as
> RowShareLock and RowExclusiveLock -- are those table-level locks?
Yes, despite the names. (The various lock-type names are pretty
horrible IMHO, but they are claimed to be Oracle-compatible.)
Anything you do with a LOCK command is a table-level lock.
> Under row-level locks we find no specific lock names mentioned.
The only row-level locking mechanism available to users is
to UPDATE, DELETE, or SELECT FOR UPDATE a particular row.
All rows affected by such a command are locked against other
such commands (but not against plain SELECT).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-09-04 15:33:30 | Re: [HACKERS] getting the oid for a new tuple in a BEFORE |
Previous Message | Tom Lane | 2001-09-04 14:51:22 | Re: Build problem with CVS version |