"Mike Mascari" <mascarm(at)mascari(dot)com> writes:
> If one wants to guarantee consistency in user-defined BEFORE
> INSERT/UPDATE triggers and trigger procedures, at the moment, is
> the only recourse SELECT FOR UPDATE? Is this the cause of
> performance problems with the current RI implementation?
Yup, and yup (or at least one cause). But it's not easy to see how
to build a multiple-locker mechanism that scales to handle very large
numbers of locked tuples. You can't really expect to keep the state
data in shared memory --- but if there's >1 locker then there's no
room for it in the on-disk tuple header, either.
regards, tom lane