Subject: Re: How does this FK constraint error happen?

From: Adrian Klaver <[email-masked]>
Date: Mon, 15 Jul 2024 08:37:32 -0700

On 7/15/24 08:18, Ron Johnson wrote:
> On Mon, Jul 15, 2024 at 11:06 AM Adrian Klaver 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On 7/15/24 07:53, Ron Johnson wrote:
>      > On Mon, Jul 15, 2024 at 10:35 AM Peter J. Holzer

>      > TAPd=# select * from rel_group_user
>      > where user_id between 1100 and 1300
>      > order by user_id;
>      >   user_id | group_id | modified_by |       modified_on
>      > ---------+----------+-------------+-------------------------
>      >      1133 |        2 |        1133 | 2024-07-15 08:43:35.669
>      >      1142 |        2 |        1142 | 2024-07-15 09:05:58.451
>      >      1147 |        2 |        1147 | 2024-07-15 09:30:37.169
>      >      1158 |        2 |        1158 | 2024-07-15 09:36:45.142
>      >      1197 |        2 |        1197 | 2024-07-15 09:52:58.477
>      >      1210 |        2 |        1210 | 2024-07-15 02:42:09.355 
>     <<<<<<<<<<<<<
> 
>     Time travel?
> 
> 
> 😞
> 
> 
>     2024-07-15 02:41:15 Deleting from
>     FISPTAPPGS401DA/TAPd.public.access_user
>     DELETE FROM public.access_user;
> 
>     Or do the cron jobs take that long to execute?
> 
> 
> The deletes from 26*3 tables (the same 26 tables in three children) took 
> from 02:40:02 to 02:41:47.
> Then a bunch of COPY statements run (pg_dump from the federation master, 
> then COPY to the federation children).  Must be done in a specific order.

I don't think it is entirely coincidental that 1210 is the only shown 
user_id with a modified_on value that is in proximity to the delete 
error. My suspicion is that actions are not happening in the exact order 
you think they are. I would think that combining DELETE FROM 
rel_group_user; and DELETE FROM public.access_user; in a single 
transaction would be a good start to fixing this.

> 
>     How is modified_on created?
> 
> 
> It's updated by the application.

At what point in the process?

> 
>      >      1229 |        2 |        1229 | 2024-07-15 08:33:48.443
>      >      1242 |        2 |        1242 | 2024-07-15 10:29:51.176
>      >      1260 |        2 |        1260 | 2024-07-15 07:36:21.182
>      >      1283 |        2 |        1283 | 2024-07-15 09:48:25.214
>      >      1288 |        2 |        1288 | 2024-07-15 08:10:33.609
>      > (11 rows)
>      >
>      > TAPd=# select user_id, login_id, created_on, modified_on
>      > TAPd-# from public.access_user
>      > TAPd-# where user_id = 1210;
>      >   user_id |  login_id  |       created_on        |       modified_on
>      >
>     ---------+------------+-------------------------+-------------------------
>      >      1210 | JORIEUSER3 | 2023-10-20 11:54:24.562 | 2024-07-15
>     02:42:09.355
>      > (1 row)
> 
>     -- 
>     Adrian Klaver
>     [email-masked] <mailto:[email-masked]>
> 

-- 
Adrian Klaver
[email-masked]

---

From: Ron Johnson <[email-masked]>
Date: Mon, 15 Jul 2024 12:21:51 -0400

On Mon, Jul 15, 2024 at 11:37 AM Adrian Klaver <[email-masked]>
wrote:

> error.

I don't think so either.

> My suspicion is that actions are not happening in the exact order
> you think they are.

modified_on is CURRENT_TIMESTAMP or NOW() or somesuch.  I'm not sure,
because I'm not privy to the code.

But I'm printing the system time in bash before every statement.

> I would think that combining DELETE FROM

That is in fact what I'm working on now.  There are 26 tables, and they
must be done in a specific order when deleting, and the reverse while
inserting.

postgres_fdw would make this easier...