From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Greg Nancarrow <gregn4422(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, Alexey Lesovsky <lesovsky(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Skipping logical replication transactions on subscriber side |
Date: | 2021-12-16 05:21:32 |
Message-ID: | CAA4eK1Ln6X=OKoNJg1yrtfPmUFFSTeEonou5C-6ncrGT0hO6Xw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-12-16 05:32:08 | Re: Optionally automatically disable logical replication subscriptions on error |
Previous Message | Masahiko Sawada | 2021-12-16 05:06:34 | Re: Skipping logical replication transactions on subscriber side |