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: | Raw Message | Whole Thread | 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 ? |