Re: row level lock and table level locks

Поиск
Список
Период
Сортировка
От Jenny -
Тема Re: row level lock and table level locks
Дата
Msg-id BAY1-F163SkS7gRzaha00002f20@hotmail.com
обсуждение исходный текст
Ответ на row level lock and table level locks  (Larry Douzie <cs4482003@yahoo.com>)
Список pgsql-hackers
Well, then if i have a transaction1 that does the following:
begin work;
select * from students where age=19 for update;.
and then another transaction2 comes along and tries to lock the same row and 
is made to wait.
Does it find out the row hes trying to lock is already locked after it 
builds its own TupleTable and has access to the t_infomask (set to 
HEAP_MARKED_FOR_UPDATE for this tuple) in the HeapTupleHeader for the 
HeapTuple in question , since HeapTuples are stored in TupleTable.
thanks

>From: Tom Lane <tgl@sss.pgh.pa.us>
>To: "Jenny -" <nat_lazy@hotmail.com>
>CC: pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] row level lock and table level locks Date: Mon, 08 
>Sep 2003 22:33:35 -0400
>
>"Jenny -" <nat_lazy@hotmail.com> writes:
> >> TupleTables are just temporary data structures to hold transiently
> >> created tuples during execution of a query.  There's usually one for
> >> each plan node.
>
> > The TupleTable will exist for the query from the point the query is made
> > untill the transaction is committed? or does the TupleTable go away as 
>soon
> > as query is finished executing?
>
>It goes away as soon as the query finishes.
>
>My answer above was mistaken --- plan nodes usually allocate slots in a
>single TupleTable created (and destroyed) by execMain.c, rather than
>each having their own TupleTable.  But it's still a query-lifetime data
>structure.
>
> > I would think the TupleTable for that query is held untill the 
>transaction
> > is committed since lock on the tuple is endtill the end of transaction
>
>You keep looking for nonexistent locks on tuples ...
>
>The only resources represented by a TupleTable entry are memory for
>a transient tuple (if we rewrote the system today, we'd forget that
>function, since short-term memory contexts can do the job better)
>or a buffer pin for a tuple that's sitting in a shared disk buffer.
>There is no reason to hold a buffer pin beyond the time that the tuple
>might actually be referenced by the query plan.
>
>            regards, tom lane

_________________________________________________________________
Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage.  
http://join.msn.com/?PAGE=features/es



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Maximum table size
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Maximum table size