| From: | "Mike Mascari" <mascarm(at)mascari(dot)com> |
|---|---|
| To: | "PostgreSQL-General-List (E-mail)" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Concurrency and locks |
| Date: | 2003-02-19 16:44:33 |
| Message-ID: | 006601c2d836$2e8cacc0$0102a8c0@mascari.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Is it possible, or could it be made possible in the future, for
a ROW locking mechanism whereby:
Transaction #1
BEGIN;
SELECT key FROM foo WHERE key = 1 FOR ????;
returns immediately with '1'
Transaction #2
BEGIN;
SELECT key FROM foo WHERE key = 1 FOR ????;
returns immediately with '1' <-- Not blocked by #1
Transaction #3
BEGIN;
UPDATE foo SET key = 2 WHERE key = 1; <-- Blocks
If one wants to guarantee consistency in user-defined BEFORE
INSERT/UPDATE triggers and trigger procedures, at the moment, is
the only recourse SELECT FOR UPDATE? Is this the cause of
performance problems with the current RI implementation?
Mike Mascari
mascarm(at)mascari(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-02-19 17:00:39 | Re: Concurrency and locks |
| Previous Message | Guy Fraser | 2003-02-19 16:38:55 | Has the attribute name for oid changed in pgsql 7.3 ? |