| From: | "Mikheev, Vadim" <VMIKHEEV(at)sectordata(dot)com> |
|---|---|
| To: | "'Stephan Szabo'" <sszabo(at)megazone23(dot)bigpanda(dot)com>, Manfred Koizar <mkoi-pg(at)aon(dot)at> |
| Cc: | Peter Schindler <pschindler(at)synchronicity(dot)com>, pg-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RI_FKey_check: foreign key constraint blocks parall |
| Date: | 2002-11-16 01:39:11 |
| Message-ID: | 3705826352029646A3E91C53F7189E325186E1@sectorbase2.sectorbase.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > void
> > > heap_mark4fk_lock_acquire(Relation relation, HeapTuple tuple) {
Just wonder how are you going to implement it - is it by using
some kind of "read-locks", ie FK transaction "locks" PK to prevent
delete (this is known as "pessimistic" approach)?
About two years ago we discussed with Jan "optimistic" approach
with using "dirty reads", when PK/FK transactions do not check
existence of FK/PK untill constraint should be checked (after
statement processed for immediate mode, at the commit time/
set constraint immediate for deferred constraints).
So, at the check time, FK transaction uses dirty reads to know
about existence/"status" of PK:
1. No PK -> abort.
2. PK (inserted?/)deleted/updated/selected for update by concurrent
transaction P -> wait for P commit/abort (just like transactions do
for concurrent same-row-update); go to 1.
3. Else (PK exists and no one changing it right now) -> proceed.
PK transaction does the same:
1. No FK -> proceed.
2. FK inserted/updated/selected for update by concurrent transaction
F -> wait for F commit/abort; go to 1.
This would be more in MVCC style -:)
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2002-11-16 02:03:13 | Re: RI_FKey_check: foreign key constraint blocks parall |
| Previous Message | Stephan Szabo | 2002-11-15 23:40:34 | Fwd: [HACKERS] RI_FKey_check: foreign key constraint blocks parallel |