One thing that is curious, though, is that when the AccessShareLock is
acquired by the stored procedure on an unrelated linking table, there
is also an AccessShareLock acquired on the primary key of the groups
table. The latter lock is understandable, but why would the procedure
need any locks
Doubtful, because users never share groups, so even though the groups
table is not part of an inheritance hierarchy, there shouldn't be any
overlap between foreign keys in the users1_groups table and the
users2_groups table in the groups table.
users1_groups links all users in the users1 subcla
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> The linking table is a pure linking table. It has a user_id and a
> group_id, each a foreign key. The user_id ties to the appropriate
> subclass user table. The group_id ties to the groups table, which is
> not part of an inheritance hierarchy.
The linking table is a pure linking table. It has a user_id and a
group_id, each a foreign key. The user_id ties to the appropriate
subclass user table. The group_id ties to the groups table, which is
not part of an inheritance hierarchy. A multicolumn primary key covers
both foreign keys in th
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> UPDATE groups
> SET count1 = v_group_count1, count2 = v_group_count2, count3
> =
>
> For instance, when run, this stored procedure could try to acquire a lock on
> users2_groups despite not directly referencin
