From: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
---|---|
To: | hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Re: Referential Integrity In PostgreSQL |
Date: | 1999-09-21 15:49:05 |
Message-ID: | 37E7A8F1.B0830950@telecom.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vadim wrote:
> > Absolutely right. The function that will fire the deferred
> > triggers must switch to READ COMMITTED isolevel while doing
> ^^^^^^^^^^^^^^
> > so.
>
> NO!
> What if one transaction deleted PK, another one inserted FK
> and now both performe RI check? Both transactions _must_
> use DIRTY READs to notice that RI violated by another
> in-progress transaction and wait for concurrent transaction...
I think we need some kind of lock on the PK table row.
This is because a rollback must allways work.
(If tx1 (insert PK) wants a rollback after tx2 did insert FK
this cannot throw a RI Violation)
I don't think we can read dirty.
We have to wait for PK lock, and decide after tx1 commited/rolled back.
On timeout we decide as follows:
Even if above tx1 (insert PK) is committed later,
we throw an error for tx2 (insert FK).
Also if a pk row is deleted/updated/inserted but not committed yet,
we ignore both old and new value for the FK check of tx2
after timeout and violate tx2.
A lock mode wait 0 would be convenient here.
Everything else imho leads to a violated integrity.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 1999-09-21 16:05:51 | Re: [HACKERS] Re: HISTORY for 6.5.2 |
Previous Message | Jan Wieck | 1999-09-21 15:28:51 | Re: [HACKERS] Re: Referential Integrity In PostgreSQL |