|From:||Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key|
|Views:||Raw Message | Whole Thread | Download mbox|
On Thu, Apr 28, 2005 at 06:47:18PM -0300, Tom Lane wrote:
> Implement sharable row-level locks, and use them for foreign key references
> to eliminate unnecessary deadlocks. This commit adds SELECT ... FOR SHARE
> paralleling SELECT ... FOR UPDATE. The implementation uses a new SLRU
> data structure (managed much like pg_subtrans) to represent multiple-
> transaction-ID sets.
One point I didn't quite understand was the business about XLogging
heap_lock_tuple. I had to reread your mail to -hackers on this issue
several times to get it (as you can see I don't fully grok the WAL
rules). Now, I believe that heap_mark4update was wrong on this, no?
Only it didn't matter because after a crash nobody cared about the
One nice side effect of this is that the 2PC patch now has this problem
solved. The bad part is that locking a tuple emits an (non-XLogFlushed)
WAL record and it may have a performance impact. (We should have better
performance overall I think, because transactions are no longer locked
on foreign key checking.)
Anyway: many thanks for updating the patch to an usable state. I'm
sorry to have inflicted all those bugs upon you.
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"La soledad es compañía"
|Next Message||Brent Verner||2005-04-29 00:49:28||Re: [proposal] protocol extension to support loadable stream filters|
|Previous Message||Tom Lane||2005-04-28 21:47:18||pgsql: Implement sharable row-level locks, and use them for foreign key|
|Next Message||Tom Lane||2005-04-29 04:17:47||Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key|
|Previous Message||User Cmaj||2005-04-28 22:35:53||pgaccess - pgaccess: first integration of new visual query builder|