On Tue, 2007-06-02 at 23:47 +0000, Gregory Stark wrote:
> "Marc Munro" <marc@bloodnok.com> 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
