> > > 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
