On Thu, Dec 10, 2020 at 8:49 PM Peter Smith <smithpb2...@gmail.com> wrote:
> So I will try to write a patch for the proposed Solution-1. > Hi Amit. FYI, here is my v3 WIP patch for the Solution1. This patch applies onto the v30 patch set [1] from the other 2PC thread: [1] https://www.postgresql.org/message-id/CAFPTHDYA8yE6tEmQ2USYS68kNt%2BkM%3DSwKgj%3Djy4AvFD5e9-UTQ%40mail.gmail.com Although incomplete, it does continue to pass all the make check, and src/test/subscription TAP tests. ==== Coded / WIP: * tablesync slot is now permanent instead of temporary * the tablesync slot cleanup (drop) code is added for DropSubscription and for finish_sync_worker functions * tablesync worked now allowing multiple tx instead of single tx * a new state (SUBREL_STATE_COPYDONE) is persisted after a successful copy_table in LogicalRepSyncTableStart. * if a relaunched tablesync finds the state is SUBREL_STATE_COPYDONE then it will bypass the initial copy_table phase. TODO / Known Issues: * The tablesync replication origin/lsn logic all needs to be updated so that tablesync knows where to restart based on information held by the now permanent slot. * the current implementation of tablesync drop slot (e.g. from DROP SUBSCRIPTION) or finish_sync_worker regenerates the tablesync slot name so it knows what slot to drop. The current code may be ok for normal use cases, but if there is an ALTER SUBSCRIPTION ... SET (slot_name = newname) it would fail to be able to find the tablesync slot. Some redesign may be needed for this part. * help / comments / cleanup * There is temporary "!!>>" excessive logging of mine scattered around which I added to help my testing during development --- Kind Regards, Peter Smith. Fujitsu Australia
v3-0002-2PC-Solution1-WIP-20201215.patch
Description: Binary data
v3-0001-2PC-change-tablesync-slot-to-use-same-two_phase-m.patch
Description: Binary data
