Re: PL/PgSQL, Inheritance, Locks, and Deadlocks
От | Thomas F.O'Connell |
---|---|
Тема | Re: PL/PgSQL, Inheritance, Locks, and Deadlocks |
Дата | |
Msg-id | f97c86cf4fcd08a40532a950ab3cbb7e@sitening.com обсуждение исходный текст |
Ответ на | Re: PL/PgSQL, Inheritance, Locks, and Deadlocks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
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 whatsoever on linking tables on which it has no direct effect (either reading or writing)? -tfo -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005 On Feb 2, 2005, at 9:41 AM, Tom Lane wrote: > "Thomas F.O'Connell" <tfo@sitening.com> 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. A multicolumn primary key covers >> both foreign keys in the linking table, and the secondary column of >> the >> key also has its own index. > > Inserts/updates in a table that has a foreign key result in locks on > the > referenced rows in the master table. Could this explain your problem? > > regards, tom lane
В списке pgsql-general по дате отправления: