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

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.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com