Re: improving foreign key locks

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: improving foreign key locks
Дата
Msg-id 1290801672-sup-1415@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: improving foreign key locks  (Florian Pflug <fgp@phlo.org>)
Ответы Re: improving foreign key locks  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
> On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
> > So I've been working on improving locks for foreign key checks, as
> > discussed in a thread started by Joel Jacobson a while ago.  I've posted
> > about this:
> > http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks/
> > http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks_part_2/
> 
> To me, the whole thing seems to be special case of allowing to not only lock whole tuples FOR UPDATE or FOR SHARE,
butalso individual fields or sets of fields. Except that for simplicity, only two sets are supported, which are
 
>   A) All fields
>   B) All fields which are included in some unique constraint, including primary keys.
> 
> I'd therefore suggest to extend the FOR SHARE / FOR UPDATE syntax to be 
>   SELECT FOR { SHARE | UPDATE } [ OF <table1>[.<field1>], ... ]
> and obtain what you call a "KEY LOCK" if (for a particular table) the set of fields is a subset of (B). Otherwise,
we'dobtain a full SHARE lock. Thus we'd always lock at least the fields the user told us to, but sometimes more than
those,for the sake of a more efficient implementation.
 

The problem with this idea is that it's not possible to implement it.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: memory leak in libxml2 - fix
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: memory leak in libxml2 - fix