Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key
Дата
Msg-id 20050428235327.GE5171@dcc.uchile.cl
обсуждение исходный текст
Ответы Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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
stored Xmax.

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[@]dcc.uchile.cl>)
"La soledad es compañía"


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Ristola
Дата:
Сообщение: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
Следующее
От: Brent Verner
Дата:
Сообщение: Re: [proposal] protocol extension to support loadable stream filters