Re: BUG #17945: Different order of definition of a constraint causes constraint violation

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: yannsalaun1(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17945: Different order of definition of a constraint causes constraint violation
Date: 2023-06-03 16:23:06
Message-ID: 59f0c5d1812ed2b83381fd575c78907541f5cc08.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, 2023-05-25 at 14:39 +0000, PG Bug reporting form wrote:
> This is a bug report with a reproducible case where different orders
> of
> definition of a SQL constraint causes different behavior.

Thank you for the report and repro! Yes, I believe this is a bug.

> - Then delete main_dir (this sets t.main_dir_id and t.main_file_id to
> NULL
> via ON DELETE SET NULL)
> DELETE FROM node WHERE id = 1;
>
> -- The second DELETE statement returns the following error.
>
> -- ERROR:  23503: insert or update on table "t" violates foreign key
> constraint "t_main_file_id_fkey"
> -- DETAIL:  Key (main_file_id)=(2) is not present in table "file".

Here's what's happening:

DELETE FROM node WHERE id = 1;
-- queues: DELETE FROM dir WHERE id = 1;
-- queues: DELETE FROM file WHERE id = 1;
-- queues: DELETE FROM node WHERE parent_id = 1;
DELETE FROM dir WHERE id = 1;
-- queues: UPDATE t SET main_dir_id = NULL WHERE main_dir_id = 1;
DELETE FROM file WHERE id = 1;
DELETE FROM node WHERE parent_id = 1;
-- queues: DELETE FROM dir WHERE id = 2;
-- queues: DELETE FROM file WHERE id = 2;
-- queues: DELETE FROM node WHERE parent_id = 2;
UPDATE t SET main_dir_id = NULL WHERE main_dir_id = 1;
-- queues RI_FKey_check_upd for t.main_file_id
DELETE FROM dir WHERE id = 2;
DELETE FROM file WHERE id = 2;
-- queues: UPDATE t SET main_file_id = NULL WHERE main_file_id = 2;
-- queues: UPDATE t SET other_file_id = NULL WHERE other_file_id = 2;
DELETE FROM node WHERE parent_id = 2;
-- perform RI_FKey_check_upd for t.main_file_id, and fails

The problem is that it's performing the check on the tuple in "t"
before all of the pending actions have completed. In this particular
case, we may be able to supress that check entirely, but I don't think
that would be correct in general (e.g. overlapping FKs).

If the constraints are declared in a different order, they end up
queuing in a different order, and all of the SET NULL events fire
before the check, so there's no error.

One idea is to to have the check events re-queue themselves if there
are still actions remaining in the queue. That might violate the rules
about executing triggers in order by name, though.

Regards,
Jeff Davis

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-06-03 19:00:01 BUG #17959: amcheck fails to find a matching index tuple for an invisible heap tuple
Previous Message Kyotaro Horiguchi 2023-06-02 21:34:18 Re: BUG #17947: Combination of replslots pgstat issues causes error/assertion failure