Re: obtaining row locking information
От | Tatsuo Ishii |
---|---|
Тема | Re: obtaining row locking information |
Дата | |
Msg-id | 20050808.233657.59648857.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: obtaining row locking information (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > If I understand correctly, it seems the above method does show a > > locked row's TID which does not block someone else. That is a little > > bit different from what I expcted. > > Well, it *could* be blocking someone else. If there were more than one > waiter for the same tuple, one of them would be holding the tuple lock > (and blocked on the transaction ID of the actual holder of the tuple), > and the other ones would be blocked on the first waiter's tuple lock. > We put this in so that the full lock manager rules would be used to > arbitrate conflicts between shared and exclusive lockers of a tuple. > The tuple lock is being used to manage the grant order and ensure that > a would-be exclusive locker doesn't get "starved out" indefinitely if > there is a continuous chain of shared-lock requests. See the notes in > heap_lock_tuple(). > > regards, tom lane Sorry, I meant: If I understand correctly, it seems the above method does *not* show a locked row's TID which does not block someone else. That is a little bit different from what I expcted. -- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: