Re: this is in plain text (row level locks)
От | Sailesh Krishnamurthy |
---|---|
Тема | Re: this is in plain text (row level locks) |
Дата | |
Msg-id | bxy65lroa7s.fsf@datafix.cs.berkeley.edu обсуждение исходный текст |
Ответ на | Re: this is in plain text (row level locks) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: this is in plain text (row level locks)
|
Список | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> Rod Taylor <rbt@rbt.ca> writes: >> It may be best to have a locking manager run as a separate >> process. Thatway it could store locks in ram or spill over to >> disk. Tom> Hmm, that might be workable. We could imagine that in place Tom> of the HEAP_MARKED_FOR_UPDATE status bit, wehave a "this row Tom> is possibly locked" hint bit. Only if you see the bit set do Tom> you need to query the lockmanager. If the answer comes back Why do you want to query the lock manager as a separate process ? Why not have the traditional approach of a lock table in shared memory, growing and shrinking as appropriate, and have each individual process update it (need to protect it with a latch of course). -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
В списке pgsql-hackers по дате отправления: