On Tue, Jul 26, 2022 at 2:30 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Fri, Jul 22, 2022 at 8:27 AM wangw.f...@fujitsu.com > <wangw.f...@fujitsu.com> wrote: > > > > On Tues, Jul 19, 2022 at 10:29 AM I wrote: > > > Attach the news patches. > > > > Not able to apply patches cleanly because the change in HEAD (366283961a). > > Therefore, I rebased the patch based on the changes in HEAD. > > > > Attach the new patches. > > + /* Check the foreign keys. */ > + fkeys = RelationGetFKeyList(entry->localrel); > + if (fkeys) > + entry->parallel_apply = PARALLEL_APPLY_UNSAFE; > > So if there is a foreign key on any of the tables which are parts of a > subscription then we do not allow changes for that subscription to be > applied in parallel? >
I think the above check will just prevent the parallelism for a xact operating on the corresponding relation not the relations of the entire subscription. Your statement sounds like you are saying that it will prevent parallelism for all the other tables in the subscription which has a table with FK. > I think this is a big limitation because having > foreign key on the table is very normal right? I agree that if we > allow them then there could be failure due to out of order apply > right? > What kind of failure do you have in mind and how it can occur? The one way it can fail is if the publisher doesn't have a corresponding foreign key on the table because then the publisher could have allowed an insert into a table (insert into FK table without having the corresponding key in PK table) which may not be allowed on the subscriber. However, I don't see any check that could prevent this because for this we need to compare the FK list for a table from the publisher with the corresponding one on the subscriber. I am not really sure if due to the risk of such conflicts we should block parallelism of transactions operating on tables with FK because those conflicts can occur even without parallelism, it is just a matter of timing. But, I could be missing something due to which the above check can be useful? -- With Regards, Amit Kapila.
