> > > > > > Probably, we also need to consider the case where the tablesync worker > > > entered an error loop and the user wants to skip the transaction? The > > > apply worker is also running at the same time but it should not clear > > > subskipxid. Similarly, the tablesync worker should not clear > > > subskipxid if the apply worker wants to skip the transaction. > > > > > > > I think for tablesync workers, the skip_xid set via this mechanism > > won't work as we don't have any remote_xid for them, and neither any > > XID is reported in the view for them. > > If the tablesync worker raises an error while applying changes after > finishing the copy, it also reports the error XID. >
Right and agreed with your assessment for the same.
IIUC each tablesync process also performs an apply stage but only applies the messages related to the single table it is responsible for. Once all tablesync workers synchronize they are all destroyed and the main apply worker takes over and applies transactions to all subscribed tables.
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.
It may even make sense, eventually for the main apply worker to skip on a subrelid basis. Since the main apply worker isn't applying transactions at the same time as the tablesync workers the non-null subrelid can also be interpreted by the main apply worker.