Re: FK check implementation

Поиск
Список
Период
Сортировка
От Nick Barnes
Тема Re: FK check implementation
Дата
Msg-id CAG+WGGm+AhDZAJh2zNhd68uxK3Kb822ZYYKS7zPQP_RfPsLW+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FK check implementation  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general

On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 10/10/2014 10:41 AM, Nick Barnes wrote:


I understand why the FK insert needs to lock on the PK row. But why is
the PK delete trying to lock the FK row? If it finds one, won't the
delete fail anyway? If it doesn't find one, what is there to lock?


I would say this has to do with setting DEFERRABLE on a constraint.
 
Any guesses why this might be? I would have thought that by this point, where we're actually performing the check, anything related to deferring the check would be behind us.

And even if we do require a lock, why FOR KEY SHARE? As I understand it, this won't lock the referencing field, which should be the only thing in the FK relation that we're interested in.

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

Предыдущее
От: Stephen Davies
Дата:
Сообщение: Re: 9.3 migration issue
Следующее
От: Jonathan Neve
Дата:
Сообщение: Where should I post 3rd party product announcements?