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: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-07-09T00:27:35Z
Lists: pgsql-hackers 
On Thu, Jul 8, 2021 at 6:28 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jul 7, 2021 at 11:47 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Tue, Jul 6, 2021 at 6:33 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > >
> > > > According to the doc, ALTER SUBSCRIPTION ... SET is used to alter
> > > > parameters originally set by CREATE SUBSCRIPTION. Therefore, we can
> > > > specify a subset of parameters that can be specified by CREATE
> > > > SUBSCRIPTION. It makes sense to me for 'disable_on_error' since it can
> > > > be specified by CREATE SUBSCRIPTION. Whereas SKIP TRANSACTION stuff
> > > > cannot be done. Are you concerned about adding a syntax to ALTER
> > > > SUBSCRIPTION?
> > > >
> > >
> > > Both for additional syntax and consistency with disable_on_error.
> > > Isn't it just a current implementation that Alter only allows to
> > > change parameters supported by Create? Is there a reason why we can't
> > > allow Alter to set/change some parameters not supported by Create?
> >
> > I think there is not reason for that but looking at ALTER TABLE I
> > thought there is such a policy.
> >
>
> If we are looking for precedent then I think we allow to set
> configuration parameters via Alter Database but not via Create
> Database. Does that address your concern?

Thank you for the info! But it seems like CREATE DATABASE doesn't
support SET in the first place. Also interestingly, ALTER SUBSCRIPTION
support both ENABLE/DISABLE and SET (enabled = on/off). I’m not sure
from the point of view of consistency with other CREATE, ALTER
commands, and disable_on_error but it might be better to avoid adding
additional syntax.

>
> > I thought the skipping transaction
> > feature is somewhat different from disable_on_error feature. The
> > former seems a feature to deal with a problem on the spot whereas the
> > latter seems a setting of a subscription. Anyway, if we use the
> > subscription option, we can reset the XID by setting 0? Or do we need
> > ALTER SUBSCRIPTION RESET?
>
> The other commands like Alter Table, Alter Database, etc, which
> provides a way to Set some parameter/option, have a Reset variant. I
> think it would be good to have it for Alter Subscription as well but
> we might want to allow other parameters to be reset by that as well.

Agreed.

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