From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Jon Swinth <jswinth(at)atomicpc(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Fix FK deadlock, but no magic please |
Date: | 2003-01-16 23:47:25 |
Message-ID: | 20030116154144.Q10566-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 16 Jan 2003, Jon Swinth wrote:
> Now I understand what you are trying to say, but what you are describing is
> normal (happens in most DBs) and rather uncommon (in my experience). General
> DB design is done so reference tables end up with a lot of read locks and
> rarely have a write lock. It would be cool if you could remove that
> contention, but not at the expense of expected write lock behaivor.
I think I may have also misunderstood which lock behavior you were worried
about. In either scheme if someone does something like:
Transaction 1: begin;
Transaction 2: begin;
Transaction 1: select for update from pk where key=1;
- Gets a write lock on row with pk.key=1
[Or does an update or a delete or whatever]
Transaction 2: insert into fk values (1);
- Needs to wait on the write lock above
That will stay true even in the dirty read scheme.
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2003-01-17 02:03:44 | Translation of the PostgreSQL manuals to Spanish is under way |
Previous Message | Stephan Szabo | 2003-01-16 23:31:49 | Re: Fix FK deadlock, but no magic please |