You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@seatunnel.apache.org by David Zollo <da...@gmail.com> on 2026/04/22 07:14:17 UTC

[DISCUSS] STIP-25: Introduce PG base CDC abstraction for Postgres and OpenGauss

Hi SeaTunnel community,

I created STIP-25 to discuss introducing a shared PG base CDC
abstraction for Apache SeaTunnel:

https://github.com/apache/seatunnel/issues/10803

The main motivation is to reduce duplicated CDC logic between the
current Postgres CDC and OpenGauss CDC implementations, while keeping
the existing user-facing connectors unchanged.

The proposal is to add an internal module:

seatunnel-connectors-v2/connector-cdc/connector-cdc-pg-base

This module would not be a user-facing connector. It would provide
shared building blocks for PG-based CDC connectors, while
connector-cdc-postgres and connector-cdc-opengauss remain the public
connector modules.

The proposed scope includes:

- Keep Postgres-CDC and Opengauss-CDC connector identifiers unchanged.
- Keep existing options and default behaviors unchanged.
- Extract common source lifecycle logic into a PG base source abstraction.
- Extract common source config creation based on the existing
JdbcSourceConfig model.
- Extract common dialect, snapshot, WAL, fetch task context, and
offset handling logic.
- Use connector-specific profiles or adapters for differences such as
driver class, Debezium connector class, table include formatting, and
exactly-once support.
- Keep checkpoint and savepoint compatibility as a hard requirement.

Compatibility is especially important. The first implementation PR
should prove that existing checkpoint and savepoint restore paths
still work, including:

- Restoring from HybridPendingSplitsState.
- Restoring from IncrementalPhaseState.
- Restoring offsets where LSN values are stored as strings.
- Verifying that Postgres snapshot, incremental, schema change, and
exactly-once behavior do not regress.

Suggested implementation split:

1. Introduce connector-cdc-pg-base and migrate Postgres internals
without user-facing behavior changes.
2. Migrate OpenGauss from depending on Postgres concrete source
classes to depending on PG base abstractions.
3. Add developer documentation for extending PG base CDC connectors.

Please take a look at the issue and share your thoughts, especially
around compatibility, module boundaries, and the relationship with
ongoing Debezium adapter refactoring work.



Best Regards,
David
Linkedin: https://www.linkedin.com/in/davidzollo