Re: table-level and row-level locks.
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.
where is 'HEAP_MARKED_FOR_UPDATE infomask bit' found ?
thanks
From: Tom Lane <tgl@sss.pgh.pa.us>
To: suzukikui@nttdata.co.jp
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] table-level and row-level locks. Date: Wed, 20 Aug
2003 14:45:23 -0400Koichi Suzuki <suzukikui@nttdata.co.jp> writes:
I need to know where such "lock marks" are stored in the source level.
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.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
_________________________________________________________________
Use custom emotions -- try MSN Messenger 6.0!
http://www.msnmessenger-download.com/tracking/reach_emoticon
On Sun, Sep 07, 2003 at 04:07:42PM -0700, Jenny - wrote:
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.where is 'HEAP_MARKED_FOR_UPDATE infomask bit' found ?
Have you ever heard of the "grep" *nix utility? It's quite useful.
Anyway, t_infomask is part of a struct called HeapTupleHeaderData,
defined somewhere in src/include/access/htup.h
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
You liked Linux a lot when he was just the gawky kid from down the block
mowing your lawn or shoveling the snow. But now that he wants to date
your daughter, you're not so sure he measures up. (Larry Greenemeier)