On Thu, Oct 28, 2021 at 6:34 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Oct 28, 2021 at 10:56 AM Masahiko Sawada <sawada.m...@gmail.com> > wrote: > > > > On Thu, Oct 28, 2021 at 1:29 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Wed, Oct 27, 2021 at 4:07 PM Amit Kapila <amit.kapil...@gmail.com> > > > wrote: > > > > > > > > On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada <sawada.m...@gmail.com> > > > > wrote: > > > > > > > > > > On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila <amit.kapil...@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? > > > > Agreed. > > > > Another thing I'm concerned is that the syntax "SKIP ( > > subscription_parameter [=value] [, ...])" looks like we can specify > > multiple options for example, "SKIP (xid = '100', lsn = > > '0/12345678’)”. Is there a case where we need to specify multiple > > options? Perhaps when specifying the target XID and operations for > > example, “SKIP (xid = 100, action = ‘insert, update’)”? > > > > Yeah, or maybe prepared transaction identifier and actions.
Prepared transactions seem not to need to be skipped since those changes are already successfully applied, though. > BTW, if we > want to proceed without the SET/RESET keyword then you can prepare the > SKIP xid patch as the second in the series and we can probably work on > the RESET syntax as a completely independent patch. Right. If we do that, the second patch can be an independent patch. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
