On 7/15/24 07:53, Ron Johnson wrote: > On Mon, Jul 15, 2024 at 10:35 AM Peter J. Holzer <hjp-pgsql@hjp.at > <mailto:hjp-pgsql@hjp.at>> wrote: > [snip] > > > Is it possible that some other process created an entry in > rel_group_user between these two queries? > > That was, in fact, the problem. At just the wrong time to impact one of > the child databases (TAPd), but not the other two (TAPb and TAPc). > > 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.
