Uh oh!
There was an error while loading. Please reload this page.
[fix](streaming-job) Fix PG replication slot leak when streaming task is cancelled during pause/resume - #62010
Merged
Merged
Conversation
Thearas
commented
Apr 1, 2026
Contributor
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
JNSimba
commented
Apr 1, 2026
MemberAuthor
run buildall |
JNSimba
commented
Apr 1, 2026
MemberAuthor
run buildall |
1 similar comment
JNSimba
commented
Apr 1, 2026
MemberAuthor
run buildall |
JNSimbaforce-pushed
the
fix_pg_msyql_pause_resume
branch
from
April 1, 2026 12:18
9bfc27d to
6997b0cCompareJNSimba
commented
Apr 1, 2026
MemberAuthor
run buildall |
JNSimba
commented
Apr 1, 2026
MemberAuthor
run nonConcurrent |
JNSimba
commented
Apr 1, 2026
MemberAuthor
run external |
2 similar comments
JNSimba
commented
Apr 2, 2026
MemberAuthor
run external |
JNSimba
commented
Apr 2, 2026
MemberAuthor
run external |
Contributor
PR approved by anyone and no changes requested. |
Contributor
PR approved by at least one committer and no changes requested. |
Uh oh!
There was an error while loading. Please reload this page.
github-actionsBot
pushed a commit
that referenced
this pull request
Apr 2, 2026
… is cancelled during pause/resume (#62010) ### What problem does this PR solve? Problem Summary: When a PostgreSQL CDC streaming job is paused and resumed, the PG replication slot can be permanently leaked, causing all subsequent tasks to fail with: `replication slot "doris_cdc_xxx" is active for PID xxx` **Root cause:** The CDC client reuses a single `SourceReader` instance per jobId (`Env.getOrCreateReader`). When FE cancels a task (PAUSE), the BE HTTP connection is closed, but the CDC client's `buildStreamRecords` thread may still be blocked in `pollRecords` (up to 15s timeout). Before the old task finishes, the new task (after RESUME) arrives at the same CDC client and calls `prepareStreamSplit`, which overwrites `this.streamReader` with a new Fetcher without closing the old one. The old Debezium reader (holding the PG replication connection) is leaked — its reference is lost, so `finishSplitRecords` in the old task's finally block closes the new Fetcher instead, and the PG slot is never released. From the logs, the slot remained occupied for 25+ minutes until the test timed out: Failed to start replication stream at LSN{0/318EBC8}; when setting up multiple connectors for the same database host, please make sure to use a distinct replication slot name for each. **Fix:** Close the previous stream/binlog reader before creating a new one in `prepareStreamSplit` (PG) and `prepareBinlogSplit` (MySQL). This ensures the old Debezium connection is properly released when a new task reuses the same SourceReader.
morningman pushed a commit
that referenced
this pull request
Apr 2, 2026
… is cancelled during pause/resume (#62010) ### What problem does this PR solve? Problem Summary: When a PostgreSQL CDC streaming job is paused and resumed, the PG replication slot can be permanently leaked, causing all subsequent tasks to fail with: `replication slot "doris_cdc_xxx" is active for PID xxx` **Root cause:** The CDC client reuses a single `SourceReader` instance per jobId (`Env.getOrCreateReader`). When FE cancels a task (PAUSE), the BE HTTP connection is closed, but the CDC client's `buildStreamRecords` thread may still be blocked in `pollRecords` (up to 15s timeout). Before the old task finishes, the new task (after RESUME) arrives at the same CDC client and calls `prepareStreamSplit`, which overwrites `this.streamReader` with a new Fetcher without closing the old one. The old Debezium reader (holding the PG replication connection) is leaked — its reference is lost, so `finishSplitRecords` in the old task's finally block closes the new Fetcher instead, and the PG slot is never released. From the logs, the slot remained occupied for 25+ minutes until the test timed out: Failed to start replication stream at LSN{0/318EBC8}; when setting up multiple connectors for the same database host, please make sure to use a distinct replication slot name for each. **Fix:** Close the previous stream/binlog reader before creating a new one in `prepareStreamSplit` (PG) and `prepareBinlogSplit` (MySQL). This ensures the old Debezium connection is properly released when a new task reuses the same SourceReader.
github-actionsBot
pushed a commit
that referenced
this pull request
Apr 23, 2026
… is cancelled during pause/resume (#62010) ### What problem does this PR solve? Problem Summary: When a PostgreSQL CDC streaming job is paused and resumed, the PG replication slot can be permanently leaked, causing all subsequent tasks to fail with: `replication slot "doris_cdc_xxx" is active for PID xxx` **Root cause:** The CDC client reuses a single `SourceReader` instance per jobId (`Env.getOrCreateReader`). When FE cancels a task (PAUSE), the BE HTTP connection is closed, but the CDC client's `buildStreamRecords` thread may still be blocked in `pollRecords` (up to 15s timeout). Before the old task finishes, the new task (after RESUME) arrives at the same CDC client and calls `prepareStreamSplit`, which overwrites `this.streamReader` with a new Fetcher without closing the old one. The old Debezium reader (holding the PG replication connection) is leaked — its reference is lost, so `finishSplitRecords` in the old task's finally block closes the new Fetcher instead, and the PG slot is never released. From the logs, the slot remained occupied for 25+ minutes until the test timed out: Failed to start replication stream at LSN{0/318EBC8}; when setting up multiple connectors for the same database host, please make sure to use a distinct replication slot name for each. **Fix:** Close the previous stream/binlog reader before creating a new one in `prepareStreamSplit` (PG) and `prepareBinlogSplit` (MySQL). This ensures the old Debezium connection is properly released when a new task reuses the same SourceReader.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
What problem does this PR solve?
Problem Summary:
When a PostgreSQL CDC streaming job is paused and resumed, the PG replication slot
can be permanently leaked, causing all subsequent tasks to fail with:
replication slot "doris_cdc_xxx" is active for PID xxxRoot cause:
The CDC client reuses a single
SourceReaderinstance per jobId (Env.getOrCreateReader).When FE cancels a task (PAUSE), the BE HTTP connection is closed, but the CDC client's
buildStreamRecordsthread may still be blocked inpollRecords(up to 15s timeout).Before the old task finishes, the new task (after RESUME) arrives at the same CDC client
and calls
prepareStreamSplit, which overwritesthis.streamReaderwith a new Fetcherwithout closing the old one. The old Debezium reader (holding the PG replication connection)
is leaked — its reference is lost, so
finishSplitRecordsin the old task's finally blockcloses the new Fetcher instead, and the PG slot is never released.
From the logs, the slot remained occupied for 25+ minutes until the test timed out:
Failed to start replication stream at LSN{0/318EBC8}; when setting up multiple connectors
for the same database host, please make sure to use a distinct replication slot name for each.
Fix:
Close the previous stream/binlog reader before creating a new one in
prepareStreamSplit(PG) andprepareBinlogSplit(MySQL). This ensures the oldDebezium connection is properly released when a new task reuses the same SourceReader.
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)