On Wed, Jul 3, 2024 at 2:16 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> 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:
>
> > 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.
>
> But if we make it wait at the very first operation that means we will
> not suck more decoded data from the network and wouldn't that make the
> sender wait for the network buffer to get sucked in by the receiver?
>
That would be true even if we wait just before applying the commit
record considering the transaction is small and the wait time is
large.
> Also, we already have a handling of parallel apply workers so if we do
> not have an issue of deadlock there or if we can handle those issues
> there we can do it here as well no?
>
Parallel apply workers won't wait for a long time. There is some
similarity and in both cases, deadlock will be detected but chances of
such implementation-related deadlocks will be higher if we start
waiting for a random amount of times. The other possibility is that we
can keep a cap on the max clock skew time above which we will give
ERROR even if the user has configured wait. This is because anyway the
system will be choked (walsender won't be able to send more data,
vacuum on publisher won't be able to remove dead rows) if we wait for
longer times. But even with that, I am not sure if waiting after
holding locks is a good idea or gives us the benefit that is worth the
risk of deadlocks.
--
With Regards,
Amit Kapila.
