You need to call sync, which I think with postgres means that it will block until the normal refresh is done. So there can be as big delay as you set the transaction poll delay (100ms by default)

Do note though that even the same node needs to call sync in code like that. Otherwise the pull is happening before the transaction has had time to process

Thanks @U8ZQ1J1RR for you answer. On a multi instance service, what is the best way to sync a node? Make the sync into a dedicated thread?

"best" really depends on what you're trying to achieve. The nodes automatically keep up to date, so you don't have to manually sync, that's only needed when you are trying to achieve a particular read-your-writes or strictly serialized consistency level with load balancing, etc.

Thanks @U899JBRPF for you answer. What do you mean with strictly serialized consistency level with load balancing?

load balancing = requests are going to multiple places without the caller seeing that, strictly serialized = things never appear to be out of order from callers perspective

Well, I shouldn't try to explain things that Jepsen has already explalined: https://jepsen.io/consistency/models/strict-serializable

It's not just one callers perspetive, it's global. So if a slow transaction is created first on a node A, then fast transaction on node B, they still should end up in A→B order, which is trivial on a single node (i.e. the node processes the transactions in order always), but not trivial on multiple nodes

https://jepsen.io/consistency is a cool page

Thanks @U8ZQ1J1RR 👍

Because I can't let go, the case for a single callers' (notice how I had missed where the ' goes in my earlier comment ; ) is solved often easily by using sticky sessions on the load balancer