On Mon, Dec 26, 2022 at 3:41 PM Melih Mutlu <m.melihmutlu@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
subscriberusually may not be even that long to hurt anything. It just seems unnecessary to me that apply worker goes
intoa 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.
