On Tue, 2007-06-02 at 23:47 +0000, Gregory Stark wrote: > "Marc Munro" <[EMAIL PROTECTED]> writes: > > > Proposal 1: Alter the way RI triggers fire, so that they complete before > > locking the row against which they fire. > > It's kind of hard to know what records the user will choose to update before > he actually does the update...
The RI triggers currently fire when a record is updated. Under my proposal they would fire in the same way but before the record is locked rather than after. Or am I missing your point? > > Proposal 2: Lock the index associated with the parent record, rather > > than the parent record itself. > > That doesn't help in our case because each version of a record has an index > entry. So even updates to unrelated fields imply index modifications. Worse, > deleting and updating don't remove the old index entries so even if you've > locked them you won't prevent people from doing exactly those operations > you're trying to avoid. I guess my proposal was incomplete. Obviously, before deleting, or updating an indexed column, a lock would have to be taken on the index. I believe this would suffice to guarantee referential integrity without blocking updates that leave the referred indexes unchanged. What you say about each version of a record having an index entry confuses me. I thought there was one index entry that lead to a chain of tuples. If this is not the case, I don't see how the current exclusive locks on indexes work to enforce uniqueness. Could you point me to somewhere in the code or the documentation that explains this? It still seems to me that if we can lock an index entry to guarantee uniqueness, we can also lock it to implement RI constraints. __ Marc
Description: This is a digitally signed message part