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