On 7/15/24 09:21, Ron Johnson wrote:
On Mon, Jul 15, 2024 at 11:37 AM Adrian Klaver
<adrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>> wrote:
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.
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.
That is why I wrote 'Time travel?'.
I suspect the modified_on time in the table is not accurately
representing when the row is modified.
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.
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...
It can't be installed?
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
