Re: Skipping logical replication transactions on subscriber side
Masahiko Sawada <sawada.mshk@gmail.com>
On Thu, Oct 28, 2021 at 1:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Oct 28, 2021 at 7:49 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Wed, Oct 27, 2021 at 2:43 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Wed, Oct 27, 2021 at 10:43 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > > > BTW how useful is specifying LSN instead of XID in practice? Given > > > > > > that this skipping behavior is used to skip the particular transaction > > > > > > (or its part of operations) in question, I’m not sure specifying LSN > > > > > > or time is useful. > > > > > > > > > > > > > > > > I think if the user wants to skip multiple xacts, she might want to > > > > > use the highest LSN to skip instead of specifying individual xids. > > > > > > > > I think it assumes that the situation where the user already knows > > > > multiple transactions that cannot be applied on the subscription but > > > > how do they know? > > > > > > > > > > Either from the error messages in the server log or from the new view > > > we are planning to add. I think such a case is possible during the > > > initial synchronization phase where apply worker went ahead then > > > tablesync worker by skipping to apply the changes on the corresponding > > > table. After that it is possible, that table sync worker failed during > > > copy and apply worker fails during the processing of some other rel. > > > > Does it mean that if both initial copy for the corresponding table by > > table sync worker and applying changes for other rels by apply worker > > fail, we skip both by specifying LSN? > > > > Yes. > > > If so, can't we disable the > > initial copy for the table and skip only the changes for other rels > > that cannot be applied? > > > > But anyway you need some way to skip changes via a particular > tablesync worker so that it can mark the relation in 'ready' state. Right. > I > think one can also try to use disable_on_error option in such > scenarios depending on how we expose it. Say, if the option means that > all workers (apply or table sync) should be disabled on an error then > it would be a bit tricky but if we can come up with a way to behave > differently for different workers then it is possible to disable one > set of workers and skip the changes in another set of workers. Yes, I would prefer to skip individual transactions in question rather than skip changes until the particular LSN. It’s not advisable to use LSN to skip changes since it has a risk of skipping unrelated changes too. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
Commits
-
Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8.
- c1da0acbb06e 15.0 landed
-
Reorder subskiplsn in pg_subscription to avoid alignment issues.
- 79b716cfb7a1 15.0 landed
-
Add ALTER SUBSCRIPTION ... SKIP.
- 208c5d65bbd6 15.0 landed
-
Optionally disable subscriptions on error.
- 705e20f8550c 15.0 cited
-
Update docs of logical replication for commit 8d74fc96db.
- 85c61ba8920b 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 cited
-
Fix regression test failure caused by commit 8d74fc96db.
- 41e66fee0516 15.0 landed
-
Add a view to show the stats of subscription workers.
- 8d74fc96db5f 15.0 landed
-
Add logical change details to logical replication worker errcontext.
- abc0910e2e0a 15.0 landed
-
Rename LOGICAL_REP_MSG_STREAM_END to LOGICAL_REP_MSG_STREAM_STOP.
- 4cd7a1896871 15.0 landed
-
Fix typo in protocol.sgml.
- e1915646658d 14.0 landed
- 0ac1aee0d7d8 15.0 landed
-
Remove unused argument in apply_handle_commit_internal().
- f4b939f1a372 14.0 landed
- 16bd4becee32 15.0 landed
-
Fix replication of in-progress transactions in tablesync worker.
- 0926e96c4934 14.0 cited
-
Reorder pg_sequence columns to avoid alignment issue
- f3b421da5f4a 10.0 cited