this should work rn since the same logic is used for tx name as in the binding

but it could diverge if something changed on one side. It's especially important since the rollback is used exactly from the binding.

Can we share some of the logic of the query or tx name creation between here and binding.rs? that'll prevent possible issues

There could be some issues due to the nature of cli calls i.e. when we run pgdog data-sync instead admin command on the running instance:

• the Manager::monitor should be running anyway, but we don't wait for it's shutdown in the cli path. That means if we fail the prepared transactions could be left on some shards and they won't be cleaned up.
• wal is also is not enabled in cli path, but on running instance it'll be enabled. We can get different behavior depending how exactly the copy command was run.

We probably should unify this and make sure we wait for shutdown and enable wal for the cli path. But that also means we should think how the old transactions should be recovered..

should i take up this as another PR, after thinking about crash recovery

I'm not sure if it's really a problem, but the commit/rollback for prepared transactions happens inside Manager::monitor handler and it's async to this code meaning we may actually start new attempt before the manager logic is fired and the cleanup could happen in the middle of new copy attempt.

@levkk wdyt? should we care about it?