Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAA4eK1KV9EroLzmmiC82dFYg4FofJzeUibuY15-j1iN-L-rxcg@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Fri, Jul 9, 2021 at 5:58 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, Jul 8, 2021 at 6:28 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Jul 7, 2021 at 11:47 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > On Tue, Jul 6, 2021 at 6:33 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > >
> > > > >
> > > > > According to the doc, ALTER SUBSCRIPTION ... SET is used to alter
> > > > > parameters originally set by CREATE SUBSCRIPTION. Therefore, we can
> > > > > specify a subset of parameters that can be specified by CREATE
> > > > > SUBSCRIPTION. It makes sense to me for 'disable_on_error' since it can
> > > > > be specified by CREATE SUBSCRIPTION. Whereas SKIP TRANSACTION stuff
> > > > > cannot be done. Are you concerned about adding a syntax to ALTER
> > > > > SUBSCRIPTION?
> > > > >
> > > >
> > > > Both for additional syntax and consistency with disable_on_error.
> > > > Isn't it just a current implementation that Alter only allows to
> > > > change parameters supported by Create? Is there a reason why we can't
> > > > allow Alter to set/change some parameters not supported by Create?
> > >
> > > I think there is not reason for that but looking at ALTER TABLE I
> > > thought there is such a policy.
> > >
> >
> > If we are looking for precedent then I think we allow to set
> > configuration parameters via Alter Database but not via Create
> > Database. Does that address your concern?
>
> Thank you for the info! But it seems like CREATE DATABASE doesn't
> support SET in the first place. Also interestingly, ALTER SUBSCRIPTION
> support both ENABLE/DISABLE and SET (enabled = on/off).
>

I think that is redundant but not sure if there is any reason behind doing so.

> I’m not sure
> from the point of view of consistency with other CREATE, ALTER
> commands, and disable_on_error but it might be better to avoid adding
> additional syntax.
>

If we can avoid introducing new syntax that in itself is a good reason
to introduce it as an option.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Diagnostic comment in LogicalIncreaseXminForSlot
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side