On Wed, Jan 26, 2022 at 12:51 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, Jan 26, 2022 at 1:43 PM David G. Johnston > <david.g.johns...@gmail.com> wrote: > > > > We probably should just provide an option for the user to specify > > "subrelid". If null, only the main apply worker will skip the given xid, > > otherwise only the worker tasked with syncing that particular table will do > > so. It might take a sequence of ALTER SUBSCRIPTION SET commands to get a > > broken initial table synchronization to load completely but at least there > > will not be any surprises as to which tables had transactions skipped and > > which did not. > > That would work but I’m concerned that the users can specify it > properly. Also, we would need to change the errcontext message > generated by apply_error_callback() so the user can know that the > error occurred in either apply worker or tablesync worker. > > Or, as another idea, since an error during table synchronization is > not common and could be resolved by truncating the table and > restarting the synchronization in practice, there might be no need > this much and we can support it only for apply worker errors. >
Yes, that is what I have also in mind. We can always extend this feature for tablesync process because it can not only fail for the specified skip_xid but also for many other reasons during the initial copy. -- With Regards, Amit Kapila.
