Search Postgresql Archives

Re: Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/13/2014 12:58 PM, Torsten Förtsch wrote:
> 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?
>


Actually, it is implemented yet.

http://www.postgresql.org/message-id/E1WWovD-0004Ts-66@xxxxxxxxxxxxxxxxxxxxxx

It'll be in 9.4.

-- 
Vik



-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux