Re: Skipping logical replication transactions on subscriber side
Masahiko Sawada <sawada.mshk@gmail.com>
On Thu, Dec 16, 2021 at 11:43 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Dec 15, 2021 at 8:19 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Wed, Dec 15, 2021 at 1:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Wed, Dec 15, 2021 at 8:19 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > On Tue, Dec 14, 2021 at 2:35 PM Greg Nancarrow <gregn4422@gmail.com> wrote: > > > > > > > > > > On Tue, Dec 14, 2021 at 3:23 PM vignesh C <vignesh21@gmail.com> wrote: > > > > > > > > > > > > While the worker is skipping one of the skip transactions specified by > > > > > > the user and immediately if the user specifies another skip > > > > > > transaction while the skipping of the transaction is in progress this > > > > > > new value will be reset by the worker while clearing the skip xid. I > > > > > > felt once the worker has identified the skip xid and is about to skip > > > > > > the xid, the worker can acquire a lock to prevent concurrency issues: > > > > > > > > > > That's a good point. > > > > > If only the last_error_xid could be skipped, then this wouldn't be an > > > > > issue, right? > > > > > If a different xid to skip is specified while the worker is currently > > > > > skipping a transaction, should that even be allowed? > > > > > > > > > > > > > We don't expect such usage but yes, it could happen and seems not > > > > good. I thought we can acquire Share lock on pg_subscription during > > > > the skip but not sure it's a good idea. It would be better if we can > > > > find a way to allow users to specify only XID that has failed. > > > > > > > > > > Yeah, but as we don't have a definite way to allow specifying only > > > failed XID, I think it is better to use share lock on that particular > > > subscription. We are already using it for add/update rel state (see, > > > AddSubscriptionRelState, UpdateSubscriptionRelState), so this will be > > > another place to use a similar technique. > > > > Yes, but it seems to mean that we disallow users to change skip_xid > > while the apply worker is skipping changes so we will end up having > > the same problem we discussed so far; > > > > I thought we just want to lock before clearing the skip_xid something > like take the lock, check if the skip_xid in the catalog is the same > as we have skipped, if it is the same then clear it, otherwise, leave > it as it is. How will that disallow users to change skip_xid when we > are skipping changes? Oh I thought we wanted to keep holding the lock while skipping changes (changing skip_xid requires acquiring the lock). So if skip_xid is already changed, the apply worker would do replorigin_advance() with WAL logging, instead of committing the catalog change? 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