Re: Skipping logical replication transactions on subscriber side

On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Dec 16, 2021 at 10:37 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Thu, Dec 16, 2021 at 11:43 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.

I've not tested it yet but replorigin_advance() with wal_log = true
seems to work for this case.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/