RE: Perform streaming logical transactions by background workers and parallel apply

On Wednesday, January 4, 2023 9:29 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Wed, Jan 4, 2023 at 6:40 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, Jan 4, 2023 at 4:52 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > > 2.
> > > + * Since the database structure (schema of subscription tables,
> > > + constraints,
> > > + * etc.) of the publisher and subscriber could be different,
> > > + applying
> > > + * transactions in parallel mode on the subscriber side can cause
> > > + some
> > > + * deadlocks that do not occur on the publisher side.
> > >
> > > I think this paragraph needs to be rephrased a bit. It is saying
> > > that some deadlock can occur on subscribers which did not occur on
> > > the publisher. I think what it should be conveying is that the
> > > deadlock can occur due to concurrently applying the
> > > conflicting/dependent transactions which are not
> > > conflicting/dependent on the publisher due to <explain reason>.
> > > Because if we create the same schema on the publisher it might not
> > > have ended up in a deadlock instead it would have been executed in
> > > sequence (due to lock waiting). So the main point we are conveying
> > > is that the transaction which was independent of each other on the
> > > publisher could be dependent on the subscriber and they can end up in
> deadlock due to parallel apply.
> > >
> >
> > How about changing it to: "We have a risk of deadlock due to
> > parallelly applying the transactions that were independent on the
> > publisher side but became dependent on the subscriber side due to the
> > different database structures (like schema of subscription tables,
> > constraints, etc.) on each side.
>
> I think this looks good to me.

Thanks for the comments.
Attach the new version patch set which changed the comments as suggested.

Best regards,
Hou zj