On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> > I doubt that it would be that simple. The application will have to intervene and tell one of the employees that their reservation has failed. It looks natural that the first one to reserve the room should get the reservation, but implementing that is more complex than resolving a conflict in the database. In fact, mostly it will be handled outside database. >> > >> >> Sure, the application needs some handling but I have tried to explain >> with a simple way that comes to my mind and how it can be realized >> with db involved. This is a known conflict detection method but note >> that I am not insisting to have "earliest_timestamp_wins". Even, if we >> want this we can have a separate discussion on this and add it later. >> > > It will be good to add a minimal set of conflict resolution strategies to begin with, while designing the feature for extensibility. I imagine the first version might just detect the conflict and throw error or do nothing. That's already two simple conflict resolution strategies with minimal efforts. We can add more complicated ones incrementally. >
Agreed, splitting the work into multiple patches would help us to finish the easier ones first.
I have thought to divide it such that in the first patch, we detect conflicts like 'insert_exists', 'update_differ', 'update_missing', and 'delete_missing' (the definition of each could be found in the initial email [1]) and throw an ERROR or write them in LOG. Various people agreed to have this as a separate committable work [2]. This can help users to detect and monitor the conflicts in a better way. I have intentionally skipped update_deleted as it would require more infrastructure and it would be helpful even without that.
Since we are in the initial months of release, it will be good to take a stock of whether the receiver receives all the information needed for most (if not all) of the conflict detection and resolution strategies. If there are any missing pieces, we may want to add those in PG18 so that improved conflict detection and resolution on a higher version receiver can still work.
In the second patch, we can implement simple built-in resolution strategies like apply and skip (which can be named as remote_apply and keep_local, see [3][4] for details on these strategies) with ERROR or LOG being the default strategy. We can allow these strategies to be configured at the global and table level.
In the third patch, we can add monitoring capability for conflicts and resolutions as mentioned by Jonathan [5]. Here, we can have stats like how many conflicts of a particular type have happened.
That looks like a plan. Thanks for chalking it out.
