Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1JhpfXHZkrckNLKE+H9SMOuJLq_eGDOuy6UKnqr_Kv9Lg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Skipping logical replication transactions on subscriber side
|
Список | pgsql-hackers |
On Wed, Oct 27, 2021 at 4:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > You have a point. The other alternatives on this line could be: > > > > > > Alter Subscription <sub_name> SKIP ( subscription_parameter [=value] [, ... ] ); > > > > > > where subscription_parameter can be one of: > > > xid = <xid_val> > > > lsn = <lsn_val> > > > ... > > > > Looks better. > > > > If we want to follow the above, then how do we allow users to reset > the parameter? One way is to allow the user to set xid as 0 which > would mean that we reset it. The other way is to allow SET/RESET > before SKIP but not sure if that is a good option. > After thinking some more on this, I think it is better to not use SET/RESET keyword here. I think we can use a model similar to how we allow setting some of the options in Alter Database: # Set the connection limit for a database: Alter Database akapila WITH connection_limit = 1; # Reset the connection limit Alter Database akapila WITH connection_limit = -1; Thoughts? With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: