Re: BUG #17945: Different order of definition of a constraint causes constraint violation - Mailing list pgsql-bugs

From Jeff Davis
Subject Re: BUG #17945: Different order of definition of a constraint causes constraint violation
Date
Msg-id 59f0c5d1812ed2b83381fd575c78907541f5cc08.camel@j-davis.com
Whole thread Raw
In response to BUG #17945: Different order of definition of a constraint causes constraint violation  (PG Bug reporting form <noreply@postgresql.org>)
List 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




pgsql-bugs by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17947: Combination of replslots pgstat issues causes error/assertion failure
Next
From: PG Bug reporting form
Date:
Subject: BUG #17959: amcheck fails to find a matching index tuple for an invisible heap tuple