"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... > 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
