Skip to content

[DPE-11044] feat(logical-replication): port the offer-side relation handler (1/5) - #266

Draft
marceloneppel wants to merge 1 commit into
16/edgefrom
lr-1-relation-module
Draft

[DPE-11044] feat(logical-replication): port the offer-side relation handler (1/5)#266
marceloneppel wants to merge 1 commit into
16/edgefrom
lr-1-relation-module

Conversation

@marceloneppel

Copy link
Copy Markdown
Member

Issue

Logical replication is disabled in both the VM and K8s charms since the 16/edge disable PRs (postgresql-operator#1258, postgresql-k8s-operator#1185) pending the module's migration onto the single-kernel library. This series ports the module; this PR ships the publisher side.

Solution

Ports the offer (publisher) half of src/relations/logical_replication.py onto the library as single_kernel_postgresql/events/logical_replication.py:

  • secret bootstrap (per-relation replication user) and grant on the offer relation,
  • publication create/alter/drop driven by the remote subscription request,
  • published-resources peer state and the replication_slots() view the Patroni render consumes — the config manager takes a logical_replication_slots callback (the placeholder left by the config migration is now wired).

Charm-module adaptations, mirroring the earlier module ports: peer/application state goes through CharmState, the primary lookup and Patroni re-render stay behind the charm bridges, and the subscription-request config option is typed in CharmConfig.

Checklist

  • I have added or updated any relevant documentation.
  • I have cleaned any remaining cloud resources from my accounts.

…andler (1/5)

Ports the publisher (offer-relation) half of the charms' logical
replication module onto the library: secret bootstrap and grant,
publication lifecycle on the offer relation, published-resources peer
state, and the replication_slots() view the Patroni render consumes.

Adapts the charm module to the library conventions: peer and
application state goes through CharmState, the status and primary
lookups stay behind the charm bridges, and the config manager takes a
logical_replication_slots callback instead of reaching into the
handler.
marceloneppel added a commit to canonical/postgresql-operator that referenced this pull request Sep 4, 2026
Re-enables the logical replication feature the library now owns
(canonical/postgresql-single-kernel-library#266..#270, pinned to
33c8fcb502677e8711c393528237e7522dc6440b until released):

- config and metadata gain the subscription-request option and the
  two logical-replication relations back,
- the charm constructs the library handler and re-wires
  apply_changed_config, retry_validations, the blocked-status
  reporting, and the update-status early-exit exemption,
- the restore action rejects clusters with an active logical
  replication relation again,
- adds tests/integration/ha_tests/test_logical_replication_circular.py
  verifying that cyclic setups block instead of looping inserts
  forever (#1085), adapted from the K8s
  charm's fix PR to the VM helpers.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
marceloneppel added a commit to canonical/postgresql-k8s-operator that referenced this pull request Sep 4, 2026
Re-enables the logical replication feature the library now owns
(canonical/postgresql-single-kernel-library#266..#270, pinned to
33c8fcb502677e8711c393528237e7522dc6440b until released):

- config and metadata gain the subscription-request option and the
  two logical-replication relations back,
- the charm constructs the library handler and re-wires
  apply_changed_config, retry_validations, the blocked-status
  reporting, and the update-status early-exit exemption,
- the restore action rejects clusters with an active logical
  replication relation again, and the charm-local commented-out
  module copy is dropped in favour of the library one,
- adds tests/integration/test_logical_replication_circular.py from
  the fix PR, verifying that direct (A <-> B) and multi-hop
  (A -> B -> C -> A) circular setups end in a blocked status instead
  of looping inserts forever (canonical/postgresql-operator#1085).

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant