From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(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: | 2022-02-14 09:16:29 |
Message-ID: | CAA4eK1+DDLOHNJWTWy-fsO8hK4E1dFvDhrKrfgW5kRUjo=Uenw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 11, 2022 at 7:40 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Thu, Jan 27, 2022 at 10:42 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> >
> > On 26.01.22 05:05, Masahiko Sawada wrote:
> > >> I think it is okay to clear after the first successful application of
> > >> any transaction. What I was not sure was about the idea of giving
> > >> WARNING/ERROR if the first xact to be applied is not the same as
> > >> skip_xid.
> > > Do you prefer not to do anything in this case?
> >
> > I think a warning would be sensible. If the user specifies to skip a
> > certain transaction and then that doesn't happen, we should at least say
> > something.
>
> Meanwhile waiting for comments on the discussion about the designs of
> both pg_stat_subscription_workers and ALTER SUBSCRIPTION SKIP feature,
> I’ve incorporated some (minor) comments on the current design patch,
> which includes:
>
> * Use LSN instead of XID.
>
I think exposing LSN is a better approach as it doesn't have the
dangers of wraparound. And, I think users can use it with the existing
function pg_replication_origin_advance() which will save us from
adding additional code for this feature. We can explain/expand in docs
how users can use the error information from view/error_logs and use
the existing function to skip conflicting transactions. We might want
to even expose error_origin to make it a bit easier for users but not
sure. I feel the need for the new syntax (and then added code
complexity due to that) isn't warranted if we expose error_LSN and let
users use it with the existing functions.
Do you see any problem with the same?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-02-14 09:18:47 | Re: Two noncritical bugs of pg_waldump |
Previous Message | Julien Rouhaud | 2022-02-14 09:14:35 | Re: Database-level collation version tracking |