Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1K2yKC-Eve+tACyfAkniy4VvLqiGU-F9Vtg0yNO7MjZzw@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 Fri, Dec 3, 2021 at 12:12 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, Dec 3, 2021 at 11:53 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > But this syntax gives you flexibility, so we can also > > > start with a simple implementation. > > > > > > > Yeah, I also think so. BTW, what do you think of providing extra > > flexibility of giving other options like 'operation', 'rel' along with > > xid? I think such options could be useful for large transactions that > > operate on multiple tables as it is quite possible that only a > > particular operation from the entire transaction is the cause of > > failure. Now, on one side, we can argue that skipping the entire > > transaction is better from the consistency point of view but I think > > it is already possible that we just skip a particular update/delete > > (if the corresponding tuple doesn't exist on the subscriber). For the > > sake of simplicity, we can just allow providing xid at this stage and > > then extend it later as required but I am not very sure of that point. > > +1 > > Skipping a whole transaction by specifying xid would be a good start. > Okay, that sounds reasonable, so let's do that for now. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: