Horton

Re: Skipping logical replication transactions on subscriber side

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, vignesh C <vignesh21@gmail.com>, Greg Nancarrow <gregn4422@gmail.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-12-02T15:08:02Z
Lists: pgsql-hackers 
On 02.12.21 07:48, Amit Kapila wrote:
> a. ALTER SUBSCRIPTION ... [SET|RESET] SKIP TRANSACTION xxx;
> b. Alter Subscription <sub_name> SET ( subscription_parameter [=value]
> [, ... ] );
> c. Alter Subscription <sub_name> On Error ( subscription_parameter
> [=value] [, ... ] );
> d. Alter Subscription <sub_name> SKIP ( subscription_parameter
> [=value] [, ... ] );
> where subscription_parameter can be one of:
> xid = <xid_val>
> lsn = <lsn_val>
> ...

> As per discussion till now, option (d) seems preferable.

I agree.

> In this, we
> need to see how and what to allow as options. The simplest way for the
> first version is to just allow one xid to be specified at a time which
> would mean that specifying multiple xids should error out. We can also
> additionally allow specifying operations like 'insert', 'update',
> etc., and then relation list (list of oids). What that would mean is
> that for a transaction we can allow which particular operations and
> relations we want to skip.

I don't know how difficult it would be, but allowing multiple xids might 
be desirable.  But this syntax gives you flexibility, so we can also 
start with a simple implementation.

> I am not sure what exactly we can provide to users to allow skipping
> initial table sync as we can't specify XID there. One option that
> comes to mind is to allow specifying a combination of copy_data and
> relid to skip table sync for a particular relation. We might think of
> not doing anything for table sync workers but not sure if that is a
> good option.

I don't think this feature should affect tablesync.  The semantics are 
not clear, and it's not really needed.  If the tablesync doesn't work, 
you can try the setup again from scratch.

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