Re: Concurrency and locks

"Mike Mascari" <mascarm@mascari.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