Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1LTBjdbQQZYw-euzkXv7YfghLsWGYFYoYxyHCK_EC833g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Skipping logical replication transactions on subscriber side
|
Список | pgsql-hackers |
On Wed, Jan 26, 2022 at 9:36 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > I think it is okay to clear after the first successful application of > > any transaction. What I was not sure was about the idea of giving > > WARNING/ERROR if the first xact to be applied is not the same as > > skip_xid. > > Do you prefer not to do anything in this case? > I am fine with clearing the skip_xid after the first successful application. But note, we shouldn't do catalog access for this, we can check if it is set in MySubscription. > > > > > > > > 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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: