From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: obtaining row locking information |
Date: | 2005-08-08 14:26:12 |
Message-ID: | 28118.1123511172@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-08-08 14:36:50 | Re: enable/disable trigger (Re: Fwd: [HACKERS] Open items) |
Previous Message | Alvaro Herrera | 2005-08-08 13:30:38 | Re: enable/disable trigger (Re: Fwd: [HACKERS] Open items) |