Horton

Re: Skipping logical replication transactions on subscriber side

Masahiko Sawada <sawada.mshk@gmail.com>

View thread View on postgr.es
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Greg Nancarrow <gregn4422@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>, Alexey Lesovsky <lesovsky@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-10-28T02:18:52Z
Lists: pgsql-hackers 
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:
> >
> > On Wed, Oct 27, 2021 at 12:35 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.
> > > >
> > > > 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? If so, can't we disable the
initial copy for the table and skip only the changes for other rels
that cannot be applied?

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/

Commits

  1. Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8.

  2. Reorder subskiplsn in pg_subscription to avoid alignment issues.

  3. Add ALTER SUBSCRIPTION ... SKIP.

  4. Optionally disable subscriptions on error.

  5. Update docs of logical replication for commit 8d74fc96db.

  6. Respect permissions within logical replication.

  7. Fix regression test failure caused by commit 8d74fc96db.

  8. Add a view to show the stats of subscription workers.

  9. Add logical change details to logical replication worker errcontext.

  10. Rename LOGICAL_REP_MSG_STREAM_END to LOGICAL_REP_MSG_STREAM_STOP.

  11. Fix typo in protocol.sgml.

  12. Remove unused argument in apply_handle_commit_internal().

  13. Fix replication of in-progress transactions in tablesync worker.

  14. Reorder pg_sequence columns to avoid alignment issue