Re: Skipping logical replication transactions on subscriber side
От | Greg Nancarrow |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAJcOf-ch1Ti28dBu=--JFToymK7bNbanFtx+9UfmFOvaddhuxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Skipping logical replication transactions on subscriber side
|
Список | pgsql-hackers |
On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > I agree that we will need a separate syntax for conflict resolution > but there is some similarity in what I proposed above (On > Error/Conflict [1]) with the existing syntax of Insert ... On > Conflict. I understand that here the context is different and we are > storing this information in the catalog but still there is some syntax > similarity and it will avoid adding new syntax variants. > The problem I see with the suggested syntax: Alter Subscription <sub_name> On Error ( subscription_parameter [= value] [, ... ] ); OR Alter Subscription <sub_name> On Conflict ( subscription_parameter [= value] [, ... ] ); is that "On Error ..." and "On Conflict" imply an action to be done on a future condition (Error/Conflict), whereas at least in this case (skip_xid) it's only AFTER the problem condition has occurred that we know the XID of the failed transaction that we want to skip. So that syntax looks a little confusing to me. Unless you had something else in mind on how it would work? Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: