Re: this is in plain text (row level locks)
От | Bruce Momjian |
---|---|
Тема | Re: this is in plain text (row level locks) |
Дата | |
Msg-id | 200307310416.h6V4GRs25541@candle.pha.pa.us обсуждение исходный текст |
Ответ на | 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 |
I was thinking of adding to TODO:* Allow shared row locks for referential integrity but how is that different from: * Implement dirty reads and use them in RI triggers --------------------------------------------------------------------------- Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > > It may be best to have a locking manager run as a separate process. > > That way it could store locks in ram or spill over to disk. > > Hmm, that might be workable. We could imagine that in place of the > HEAP_MARKED_FOR_UPDATE status bit, we have a "this row is possibly > locked" hint bit. Only if you see the bit set do you need to query > the lock manager. If the answer comes back that no lock is held, > you can clear the bit --- so no need for any painful "undo" stuff > after a crash, and no communication overhead in the normal case. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: