On Thu, Jun 20, 2024 at 5:06 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > On Thu, Jun 20, 2024 at 3:21 PM Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat >> <ashutosh.bapat....@gmail.com> wrote: >> > >> > On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila <amit.kapil...@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. >
Good point. This can help us to detect conflicts if required even when we move to a higher version. As we continue to discuss/develop the features, I hope we will be able to see any missing pieces. >> >> >> 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. > Thanks! -- With Regards, Amit Kapila.
