On Wed, Jan 4, 2023 at 6:40 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jan 4, 2023 at 4:52 PM Dilip Kumar <dilipbal...@gmail.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
