On Wed, Jun 5, 2024 at 9:12 AM shveta malik <shveta.ma...@gmail.com> wrote: > > On Tue, Jun 4, 2024 at 9:37 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > > > > > > > > > > > Conflict Resolution > > > > > ---------------- > > > > > a) latest_timestamp_wins: The change with later commit timestamp > > > > > wins. > > > > > b) earliest_timestamp_wins: The change with earlier commit > > > > > timestamp wins. > > > > Can you share the use case of "earliest_timestamp_wins" resolution > > method? It seems after the initial update on the local node, it will > > never allow remote update to succeed which sounds a bit odd. Jan has > > shared this and similar concerns about this resolution method, so I > > have added him to the email as well. > > I do not have the exact scenario for this. But I feel, if 2 nodes are > concurrently inserting different data against a primary key, then some > users may have preferences that retain the row which was inserted > earlier. It is no different from latest_timestamp_wins. It totally > depends upon what kind of application and requirement the user may > have, based on which, he may discard the later coming rows (specially > for INSERT case).
I haven't read the complete design yet, but have we discussed how we plan to deal with clock drift if we use timestamp-based conflict resolution? For example, a user might insert something conflicting on node1 first and then on node2. However, due to clock drift, the timestamp from node2 might appear earlier. In this case, if we choose "earliest timestamp wins," we would keep the changes from node2. I haven't fully considered if this would cause any problems, but users might detect this issue. For instance, a client machine might send a change to node1 first and then, upon confirmation, send it to node2. If the clocks on node1 and node2 are not synchronized, the changes might appear in a different order. Does this seem like a potential problem? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
