>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?




---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
>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?
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Sun, 7 Sep 2003 19:45:53 -0700 (PDT)
Larry Douzie <cs4482003@yahoo.com>
row level lock and table level locks
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

Sun, 07 Sep 2003 23:24:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: row level lock and table level locks 
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"

Sun, 7 Sep 2003 23:35:07 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: row level lock and table level locks
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:
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 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

---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
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:
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 lockedthe row to commit or abort. (Waiting for a transaction is done byhaving every transaction take out exclusive lock on its xact ID when itstarts; 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 fortransparency :-( ... it do
 es the
 jobs it's supposed to do, but it's notalways 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
Sun, 7 Sep 2003 20:45:56 -0700 (PDT)
Larry Douzie <cs4482003@yahoo.com>
Re: row level lock and table level locks 
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

Sun, 07 Sep 2003 23:49:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: row level lock and table level locks 
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

Sun, 07 Sep 2003 23:54:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: row level lock and table level locks 
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
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:
cregards, 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
Sun, 7 Sep 2003 21:05:49 -0700 (PDT)
Larry Douzie <cs4482003@yahoo.com>
Re: row level lock and table level locks 