Re: referential Integrity and SHARE locks

"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...

> 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.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com