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

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