Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID? - Mailing list pgsql-general

From Torsten Förtsch
Subject Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID?
Date
Msg-id 534A6DD7.5060007@gmx.net
Whole thread Raw
Responses Re: Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID?  (Vik Fearing <vik.fearing@dalibo.com>)
List 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 by date:

Previous
From: Jan Wieck
Date:
Subject: Re: WAL Replication Server + repmgr + Slony
Next
From: Vik Fearing
Date:
Subject: Re: Why do we need an AccessExclusiveLock to validate a FK constraint marked as NOT VALID?