Re: Single transaction in the tablesync worker?
От | Peter Smith |
---|---|
Тема | Re: Single transaction in the tablesync worker? |
Дата | |
Msg-id | CAHut+Pv8ShLmrjCriVU+tprk_9b2kwBxYK2oGSn5Eb__kWVc7A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Single transaction in the tablesync worker? (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: Single transaction in the tablesync worker?
Re: Single transaction in the tablesync worker? |
Список | pgsql-hackers |
Hi Amit. PSA my v9 WIP patch for the Solution1 which addresses some recent review comments, and other minor changes. ==== Features: * tablesync slot is now permanent instead of temporary. The tablesync slot name is no longer tied to the Subscription slot na * 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. * tablesync sets up replication origin tracking in LogicalRepSyncTableStart (similar as done for the apply worker). The origin is advanced when first created. * tablesync replication origin tracking is cleaned up during DropSubscription and/or process_syncing_tables_for_apply. * The DropSubscription cleanup code was enhanced in v7 to take care of crashed sync workers. * Minor updates to PG docs TODO / Known Issues: * Source includes temporary "!!>>" excessive logging which I added to help testing during development * Address review comments --- Kind Regards, Peter Smith. Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: