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 <[EMAIL PROTECTED]>
To: "Jenny -" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [HACKERS] row level lock and table level locks Date: Mon, 08 Sep 2003 22:33:35 -0400
"Jenny -" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
