On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Wed, Jul 3, 2024 at 11:00 AM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > > Yes, I also think it should be independent of CDR. IMHO, it should be
> > > > based on the user-configured maximum clock skew tolerance and can be
> > > > independent of CDR.
> > >
> > > +1
> > >
> > > > IIUC we would make the remote apply wait just
> > > > before committing if the remote commit timestamp is ahead of the local
> > > > clock by more than the maximum clock skew tolerance, is that correct?
> > >
> > > +1 on condition to wait.
> > >
> > > But I think we should make apply worker wait during begin
> > > (apply_handle_begin) instead of commit. It makes more sense to delay
> > > the entire operation to manage clock-skew rather than the commit
> > > alone. And only then CDR's timestamp based resolution which are much
> > > prior to commit-stage can benefit from this. Thoughts?
> >
> > But do we really need to wait at apply_handle_begin()? I mean if we
> > already know the commit_ts then we can perform the conflict resolution
> > no? I mean we should wait before committing because we are
> > considering this remote transaction to be in the future and we do not
> > want to confirm the commit of this transaction to the remote node
> > before the local clock reaches the record commit_ts to preserve the
> > causal order. However, we can still perform conflict resolution
> > beforehand since we already know the commit_ts. The conflict
> > resolution function will be something like "out_version =
> > CRF(version1_commit_ts, version2_commit_ts)," so the result should be
> > the same regardless of when we apply it, correct? From a performance
> > standpoint, wouldn't it be beneficial to perform as much work as
> > possible in advance? By the time we apply all the operations, the
> > local clock might already be in sync with the commit_ts of the remote
> > transaction. Am I missing something?
> >
>
> But waiting after applying the operations and before applying the
> commit would mean that we need to wait with the locks held. That could
> be a recipe for deadlocks in the system. I see your point related to
> performance but as we are not expecting clock skew in normal cases, we
> shouldn't be too much bothered on the performance due to this. If
> there is clock skew, we expect users to fix it, this is just a
> worst-case aid for users.
>
Please find the new patch set. patch004 is the new patch which
attempts to implement:
1) Either wait or error out on clock skew as configured. Please note
that currently wait is implemented during 'begin'. Once the ongoing
discussion is concluded, it can be changed as needed.
2) last_update_wins resolver. Thanks Nisha for providing the resolver
related changes.
Next to be done:
1) parallel apply worker related changes as mentioned in [1]
2) cap on wait time due to clock skew
3) resolvers for delete_differ as conflict detection thread [2] has
implemented detection for that.
[1]: https://www.postgresql.org/message-id/CAFiTN-sf23K%3DsRsnxw-BKNJqg5P6JXcqXBBkx%3DEULX8QGSQYaw%40mail.gmail.com
[2]:
https://www.postgresql.org/message-id/OS0PR01MB571686E464A325F26CEFCCEF94DD2%40OS0PR01MB5716.jpnprd01.prod.outlook.com
thanks
Shveta