Re: row level lock and table level locks

From: Larry Douzie <cs4482003(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: row level lock and table level locks
Date: 2003-09-08 03:45:56
Message-ID: 20030908034556.52297.qmail@web60202.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-09-08 03:49:41 Re: row level lock and table level locks
Previous Message Alvaro Herrera 2003-09-08 03:35:07 Re: row level lock and table level locks