On Mon, Dec 26, 2022 at 3:41 PM Melih Mutlu <m.melihmu...@gmail.com> wrote: > >> Do you have any use case in mind where the user has added a table to >> the publication even though she doesn't want it to be replicated? One >> thing that came to my mind is that due to some reason after adding a >> table to the publication, there is some delay in creating the table on >> the subscriber and then refreshing the publication and during that >> time user expects replication to proceed smoothly. But for that isn't >> it better that the user completes the setup on the subscriber before >> performing operations on such a table? Because say there is some error >> in the subscriber-side setup that the user misses then it would be a >> surprise for a user to not see the table data. In such a case, an >> ERROR/LOG information could be helpful for users. > > > I don't really see a specific use case for this. The delay between creating a > table on publisher and then on subscriber usually may not be even that long > to hurt anything. It just seems unnecessary to me that apply worker goes into > a failure loop until someone creates the table on the subscriber, even though > the table will not be replicated immediately. >
To avoid the failure loop, users can use disable_on_error subscription parameter. I see your point but not sure if it is worth changing the current behavior without any specific use case which we want to address with this change. -- With Regards, Amit Kapila.
