Thread: row level lock and table level locks
>A row lock is represented by storing the locking transaction's ID in
xmax and setting
xmax and setting
>the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is
needed to distinguish
needed to distinguish
>this from the case where the transaction is
deleting the tuple.
Is there a similar bit modified if the row in question is being waited
upon by some transaction?
deleting the tuple.
Is there a similar bit modified if the row in question is being waited
upon by some transaction?
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Larry Douzie <cs4482003@yahoo.com> writes: >> A row lock is represented by storing the locking transaction's ID in >> xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is >> needed to distinguish this from the case where the transaction is >> deleting the tuple. > Is there a similar bit modified if the row in question is being waited > upon by some transaction? No. We handle that case by waiting for the transaction that's locked the row to commit or abort. (Waiting for a transaction is done by having every transaction take out exclusive lock on its xact ID when it starts; then would-be waiters try to take share lock on the xact ID, causing them to block till the exclusive lock is released.) In general, the Postgres lock management code is not designed for transparency :-( ... it does the jobs it's supposed to do, but it's not always easy to inspect the visible state to find out what's happening. Perhaps someday someone will get motivated to rewrite this stuff. regards, tom lane
On Sun, Sep 07, 2003 at 11:24:42PM -0400, Tom Lane wrote: > No. We handle that case by waiting for the transaction that's locked > the row to commit or abort. (Waiting for a transaction is done by > having every transaction take out exclusive lock on its xact ID when it > starts; then would-be waiters try to take share lock on the xact ID, > causing them to block till the exclusive lock is released.) This is interesting in the nested transactions case. Suppose a transaction takes a lock on a tuple. If another transaction tries to do the same, it has to wait for the previous transaction to finish. That's pretty clear and simple. Now, if a subtransaction has got a lock on some tuple, and another transaction tree tries to grab the lock on that tuple, it should have to wait for the entire transaction tree to finish. But what if the subtransaction that got the lock aborts? Maybe the waiter could awake at that point. I invented a "CommitContext", that is supposed to hold things that should be kept in memory if a subtransaction commits, and discarded if it aborts (think async notifies, smgr pending deletes). The list of things has to be kept until the transaction tree is finished, but can be discarded in a single operation if any subtransaction aborts. Maybe some similar thing can be done with locks? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "El conflicto es el camino real hacia la union"
Is there a array or some sort of datastructures that store all the HeapTupleDatas for all rows in the db?
like we have the LockData storing all the current locks in the db.
thanks!
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Larry Douzie writes:
>> A row lock is represented by storing the locking transaction's ID in
>> xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is
>> needed to distinguish this from the case where the transaction is
>> deleting the tuple.
> Is there a similar bit modified if the row in question is being waited
> upon by some transaction?
No. We handle that case by waiting for the transaction that's locked
the row to commit or abort. (Waiting for a transaction is done by
having every transaction take out exclusive lock on its xact ID when it
starts; then would-be waiters try to take share lock on the xact ID,
causing them to block till the exclusive lock is released.)
In general, the Postgres lock management code is not designed for
transparency :-( ... it do es the jobs it's supposed to do, but it's not
always easy to inspect the visible state to find out what's happening.
Perhaps someday someone will get motivated to rewrite this stuff.
regards, tom lane
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Alvaro Herrera <alvherre@dcc.uchile.cl> writes: > Now, if a subtransaction has got a lock on some tuple, and another > transaction tree tries to grab the lock on that tuple, it should have to > wait for the entire transaction tree to finish. But what if the > subtransaction that got the lock aborts? Maybe the waiter could awake > at that point. Yes. At present, a transaction that aborts will *immediately* drop all its locks (and other shared resources), even before waiting for its client to acknowledge the failure. Seems to me the same should hold true of subtransactions. regards, tom lane
Larry Douzie <cs4482003@yahoo.com> writes: > Is there a array or some sort of datastructures that store all the > HeapTupleDatas for all rows in the db? Er, wouldn't that be the database files? regards, tom lane
Larry Douzie writes:
> Is there a array or some sort of datastructures that store all the
> HeapTupleDatas for all rows in the db?
Er, wouldn't that be the database files?
> Is there a array or some sort of datastructures that store all the
> HeapTupleDatas for all rows in the db?
Er, wouldn't that be the database files?
What i mean is, whats the pointer name to this list of HeapTupleDatas?
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
c
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
HI, I found out that TupleTable stores per-tuple information(it stores HeapTupleData) and that also there are multiple TupleTables in the db at a time.Based on what are diffrent TupleTables created? thank you Jenny >From: Larry Douzie <cs4482003@yahoo.com> >To: Tom Lane <tgl@sss.pgh.pa.us> >CC: pgsql-hackers@postgresql.org >Subject: Re: [HACKERS] row level lock and table level locks Date: Sun, 7 >Sep 2003 21:05:49 -0700 (PDT) > >Larry Douzie writes: > > Is there a array or some sort of datastructures that store all the > > HeapTupleDatas for all rows in the db? > >Er, wouldn't that be the database files? > >What i mean is, whats the pointer name to this list of HeapTupleDatas? > >Tom Lane <tgl@sss.pgh.pa.us> wrote: >c >regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster > >--------------------------------- >Do you Yahoo!? >Yahoo! SiteBuilder - Free, easy-to-use web site design software _________________________________________________________________ Express yourself with MSN Messenger 6.0 -- download now! http://www.msnmessenger-download.com/tracking/reach_general
"Jenny -" <nat_lazy@hotmail.com> writes: > I found out that TupleTable stores per-tuple information(it stores > HeapTupleData) and that also there are multiple TupleTables in the db at a > time.Based on what are diffrent TupleTables created? TupleTables are just temporary data structures to hold transiently created tuples during execution of a query. There's usually one for each plan node. regards, tom lane
>TupleTables are just temporary data structures to hold transiently >created tuples during execution of a query. There's usually one for >each plan node. > whats a 'plan node'? >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 12:49:51 -0400 > >"Jenny -" <nat_lazy@hotmail.com> writes: > > I found out that TupleTable stores per-tuple information(it stores > > HeapTupleData) and that also there are multiple TupleTables in the db at >a > > time.Based on what are diffrent TupleTables created? > >TupleTables are just temporary data structures to hold transiently >created tuples during execution of a query. There's usually one for >each plan node. > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster _________________________________________________________________ Compare Cable, DSL or Satellite plans: As low as $29.95. https://broadband.msn.com
On Mon, Sep 08, 2003 at 10:17:46AM -0700, Jenny - wrote: > >TupleTables are just temporary data structures to hold transiently > >created tuples during execution of a query. There's usually one for > >each plan node. > whats a 'plan node'? Have you tried reading the documentation, source code and the slides of Tom and Bruce's presentations? They all are very valuable resources. I believe there's a good set of slides by Bruce in http://developer.postgresql.org that explain these things in a general manner. Armed with that you can try to read the source code. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "I dream about dreams about dreams", sang the nightingale under the pale moon (Sandman)
>TupleTables are just temporary data structures to hold transiently >created tuples during execution of a query. There's usually one for >each plan node. So, if i have the following transaction: begin work; select * from students where a age=19 for update; lock table studens in share mode; commit; 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? 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 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 12:49:51 -0400 > >"Jenny -" <nat_lazy@hotmail.com> writes: > > I found out that TupleTable stores per-tuple information(it stores > > HeapTupleData) and that also there are multiple TupleTables in the db at >a > > time.Based on what are diffrent TupleTables created? > cc> > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster _________________________________________________________________ Express yourself with MSN Messenger 6.0 -- download now! http://www.msnmessenger-download.com/tracking/reach_general
"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
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