Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID?
В списке pgsql-general по дате отправления:
| От | Torsten Förtsch |
|---|---|
| Тема | Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID? |
| Дата | |
| Msg-id | 534A6DD7.5060007@gmx.net обсуждение исходный текст |
| Ответы |
Re: Why do we need an AccessExclusiveLock to validate a
FK constraint marked as NOT VALID?
|
| Список | pgsql-general |
Hi, currently, ALTER TABLE VALIDATE CONSTRAINT for foreign key constraints acquires an AccessExclusiveLock on the referencing table. Why? If the constraint is in place but not validated (ADD CONSTRAINT ... NOT VALID) it already prevents new modifications from violating the constraint. The code that is called to validate the constraint, RI_Initial_Check, contains this comment: * We expect that the caller has made provision to prevent any problems * caused by concurrent actions. This could be either by locking rel and * pkrel at ShareRowExclusiveLock or higher, or by otherwise ensuring * that triggers implementing the checks are already active. * Hence, we do not need to lock individual rows for the check. Doesn't the presence of the NOT VALID constraint qualify as "otherwise ensuring that triggers implementing the checks are already active"? Is there any deeper reason? Or is it simply not implemented yet? Thanks, Torsten
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера