Hi Amit. PSA the v18 patch for the Tablesync Solution1.
Main differences from v17: + Design change to use TEMPORARY tablesync slots [ak0122] means lots of the v17 slot cleanup code became unnecessary. + Small refactor in LogicalReplicationSyncTableStart to fix a deadlock scenario. + Addressing some review comments [ak0121]. [ak0121] https://www.postgresql.org/message-id/CAA4eK1LGxuB_RTfZ2HLJT76wv%3DFLV6UPqT%2BFWkiDg61rvQkkmQ%40mail.gmail.com [ak0122] https://www.postgresql.org/message-id/CAA4eK1LS0_mdVx2zG3cS%2BH88FJiwyS3kZi7zxijJ_gEuw2uQ2g%40mail.gmail.com ==== Features: * The tablesync slot name is no longer tied to the Subscription slot name. * The tablesync worker is now allowing multiple tx instead of single tx * A new state (SUBREL_STATE_FINISHEDCOPY) is persisted after a successful copy_table in tablesync's LogicalRepSyncTableStart. * If a re-launched tablesync finds state SUBREL_STATE_FINISHEDCOPY then it will bypass the initial copy_table phase. * Now tablesync sets up replication origin tracking in LogicalRepSyncTableStart (similar as done for the apply worker). The origin is advanced when first created. * The tablesync replication origin tracking record is cleaned up by: - process_syncing_tables_for_apply - DropSubscription - AlterSubscription_refresh * Updates to PG docs. * New TAP test case Known Issues: * None. --- Kind Regards, Peter Smith. Fujitsu Australia
v18-0001-Tablesync-Solution1.patch
Description: Binary data
v18-0002-Tablesync-extra-logging.patch
Description: Binary data