Constraints are checked at the time of:

• Statement execution, for nondeferred constraints
• COMMIT, for deferred constraints

So the order is (case: DML statement, followed by COMMIT):

1. Nondeferred constraints checked
2. COMMIT issued
3. Deferred constraints checked
4. COMMIT complete

Non-deferred constraints are enforced at the end of every DML statement and a violation causes the statement to roll back.

Deferred constraints are enforced when a transaction is committed and a violation causes the transaction to roll back.

A constraint that is defined as deferrable can be specified as one of the following:

• Initially immediable: specifies that by default it must function as an immediate constraint unless explicitly set otherwise using SET CONSTRAINT {constraint name, … ALL} {IMMEDIATE DEFERRED}
• Initially deferred: specifies that by default the constraint must be enforced only at the end of the transaction.

To appreciate the value of initially deferred let us consider the chicken-egg problem.

To better deal with situations where data must be temporarily in violation of a constraint, you can designate a constraint to be in various states.
An integrity constraint can be ENABLED or DISABLED. This applies to newly entered data.
An integrity constraint can VALIDATE or NOVALIDATE existing data.
To sumarize, an integrity constraint can be in one of the four states:

• DISABLE NOVALIDATE (often used when the data is from an already validated source and the table is read-only, so no new data is being entered into the table).
• DISABLE VALIDATE (used when the existing data must be validated but the data is not going to be modified and the index is not otherwise needed for performance).
• ENABLE NOVALIDATE (used so that existing constraint violations can be corrected, and at the same time, new violations are not allowed to enter the system).
• ENABLE VALIDATE (both new and existing data must conform to the constraint)