Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1Ln6X=OKoNJg1yrtfPmUFFSTeEonou5C-6ncrGT0hO6Xw@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 Thu, Dec 16, 2021 at 10:37 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Dec 16, 2021 at 11:43 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > I thought we just want to lock before clearing the skip_xid something > > like take the lock, check if the skip_xid in the catalog is the same > > as we have skipped, if it is the same then clear it, otherwise, leave > > it as it is. How will that disallow users to change skip_xid when we > > are skipping changes? > > Oh I thought we wanted to keep holding the lock while skipping changes > (changing skip_xid requires acquiring the lock). > > So if skip_xid is already changed, the apply worker would do > replorigin_advance() with WAL logging, instead of committing the > catalog change? > Right. BTW, how are you planning to advance the origin? Normally, a commit transaction would do it but when we are skipping all changes, the commit might not do it as there won't be any transaction id assigned. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: