On Wed, Dec 1, 2021 at 11:57 AM houzj.f...@fujitsu.com <houzj.f...@fujitsu.com> wrote: > > On Wednesday, December 1, 2021 1:23 PM Masahiko Sawada > <sawada.m...@gmail.com> wrote: > > Okay, I've attached an updated patch. Please review it. > > > > I agreed that checking the result only once makes the test more stable. > The patch looks good to me. >
Pushed. Now, coming back to the skip_xid patch. To summarize the discussion in that regard so far, we have discussed various alternatives for the syntax like: a. ALTER SUBSCRIPTION ... [SET|RESET] SKIP TRANSACTION xxx; b. Alter Subscription <sub_name> SET ( subscription_parameter [=value] [, ... ] ); c. Alter Subscription <sub_name> On Error ( subscription_parameter [=value] [, ... ] ); d. Alter Subscription <sub_name> SKIP ( subscription_parameter [=value] [, ... ] ); where subscription_parameter can be one of: xid = <xid_val> lsn = <lsn_val> ... We didn't prefer (a) as it can lead to more keywords as we add more options; (b) as we want these new skip options to behave and be set differently than existing subscription properties because of the difference in their behavior; (c) as that sounds more like an action to be performed on a future condition (error/conflict) whereas here we already knew that an error has happened; As per discussion till now, option (d) seems preferable. In this, we need to see how and what to allow as options. The simplest way for the first version is to just allow one xid to be specified at a time which would mean that specifying multiple xids should error out. We can also additionally allow specifying operations like 'insert', 'update', etc., and then relation list (list of oids). What that would mean is that for a transaction we can allow which particular operations and relations we want to skip. I am not sure what exactly we can provide to users to allow skipping initial table sync as we can't specify XID there. One option that comes to mind is to allow specifying a combination of copy_data and relid to skip table sync for a particular relation. We might think of not doing anything for table sync workers but not sure if that is a good option. Thoughts? -- With Regards, Amit Kapila.
