From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Single transaction in the tablesync worker? |
Date: | 2021-01-19 09:01:48 |
Message-ID: | CAHut+Pt9+g8qQR0kMC85nY-O4uDQxXboamZAYhHbvkebzC9fAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Amit.
PSA the v17 patch for the Tablesync Solution1.
Main differences from v16:
+ Small refactor for DropSubscription to correct the "make check" deadlock
+ Added test case
+ Some comment wording
====
Features:
* The tablesync slot is now permanent instead of temporary.
* 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.
* Cleanup of tablesync resources:
- The tablesync slot cleanup (drop) code is added for
process_syncing_tables_for_sync functions.
- The tablesync replication origin tracking is cleaned
process_syncing_tables_for_apply.
- A tablesync function to cleanup its own slot/origin is called fro
ProcessInterrupts. This is indirectly invoked by
DropSubscription/AlterSubscription when they signal the tablesync
worker to stop.
* Updates to PG docs.
* New TAP test case
TODO / Known Issues:
* None known.
---
Kind Regards,
Peter Smith.
Fujitsu Australia
Attachment | Content-Type | Size |
---|---|---|
v17-0001-Tablesync-Solution1.patch | application/octet-stream | 36.3 KB |
v17-0002-Tablesync-extra-logging.patch | application/octet-stream | 6.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2021-01-19 09:09:16 | Re: ResourceOwner refactoring |
Previous Message | Masahiro Ikeda | 2021-01-19 08:55:18 | Re: pg_stat_statements oddity with track = all |