Horton

Re: Skipping logical replication transactions on subscriber side

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <sawada.mshk@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-28T09:37:14Z
Lists: pgsql-hackers 
On Thu, Oct 28, 2021 at 10:48 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> 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:
> > >
> > > >
> > > > 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.
>

Fair enough but I think providing LSN is also useful if user can
identify the same easily as otherwise there might be more
administrative work to make replication progress.

-- 
With Regards,
Amit Kapila.

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