-
Bug
-
Resolution: Obsolete
-
Major
-
None
-
False
-
-
False
In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.
Bug report
For bug reports, provide this information, please:
What Debezium connector do you use and what version?
- Debezium Connector for PostgreSQL, version 3.2.2.Final.
What is the connector configuration?
(Relevant part of the configuration)
json
What is the captured database version and mode of deployment?
- Database: PostgreSQL (version can be inferred from the PostgreSQL JDBC driver 42.7.7).
- Deployment: Not specified, but the issue is independent of the deployment mode.
What behavior do you expect?
- The Debezium connector should successfully start the logical decoding replication stream using the replication slot firstpumper1cld11 and begin capturing changes from the database.
What behavior do you see?
- The connector fails to start the replication stream and enters a retry loop. It logs a warning that it is waiting for 10 seconds before the 3rd attempt (out of a maximum of 6). The operation fails with a PSQLException stating: ERROR: replication slot "firstpumper1cld11" is active for PID 113. This indicates that the replication slot is already locked by another process (with Process ID 113), preventing the current connector from acquiring it.
Do you see the same behaviour using the latest released Debezium version?
- This issue is environment-specific (a locked resource) and is not directly caused by a bug in a specific Debezium version. However, it should be verified with the latest version to rule out any fixes related to connection handling or slot management.
Do you have the connector logs, ideally from start till finish?
WARN Postgres||streaming Failed to start replication stream at LSN{0/2046C68}, waiting for PT10S ms and retrying, attempt number 3 over 6 [io.debezium.connector.postgresql.connection.PostgresReplicationConnection]
org.postgresql.util.PSQLException: ERROR: replication slot "firstpumper1cld11" is active for PID 113
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2734) ~[postgresql-42.7.7.jar:42.7.7]
at org.postgresql.core.v3.QueryExecutorImpl.processCopyResults(QueryExecutorImpl.java:1310) ~[postgresql-42.7.7.jar:42.7.7]
at org.postgresql.core.v3.QueryExecutorImpl.startCopy(QueryExecutorImpl.java:981) ~[postgresql-42.7.7.jar:42.7.7]
at org.postgresql.core.v3.replication.V3ReplicationProtocol.initializeReplication(V3ReplicationProtocol.java:62) ~[postgresql-42.7.7.jar:42.7.7]
at org.postgresql.core.v3.replication.V3ReplicationProtocol.startLogical(V3ReplicationProtocol.java:45) ~[postgresql-42.7.7.jar:42.7.7]
at org.postgresql.replication.fluent.ReplicationStreamBuilder$1.start(ReplicationStreamBuilder.java:38) ~[postgresql-42.7.7.jar:42.7.7]
at org.postgresql.replication.fluent.logical.LogicalStreamBuilder.start(LogicalStreamBuilder.java:41) ~[postgresql-42.7.7.jar:42.7.7]
at io.debezium.connector.postgresql.connection.PostgresReplicationConnection.startPgReplicationStream(PostgresReplicationConnection.java:895) ~[debezium-connector-postgres-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.connector.postgresql.connection.PostgresReplicationConnection.createReplicationStream(PostgresReplicationConnection.java:737) ~[debezium-connector-postgres-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.connector.postgresql.connection.PostgresReplicationConnection.startStreaming(PostgresReplicationConnection.java:523) ~[debezium-connector-postgres-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.connector.postgresql.PostgresStreamingChangeEventSource.execute(PostgresStreamingChangeEventSource.java:157) ~[debezium-connector-postgres-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.connector.postgresql.PostgresStreamingChangeEventSource.execute(PostgresStreamingChangeEventSource.java:49) ~[debezium-connector-postgres-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.pipeline.ChangeEventSourceCoordinator.streamEvents(ChangeEventSourceCoordinator.java:326) ~[debezium-core-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.pipeline.ChangeEventSourceCoordinator.executeChangeEventSources(ChangeEventSourceCoordinator.java:207) ~[debezium-core-3.2.2.Final.jar:3.2.2.Final]
at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:147) ~[debezium-core-3.2.2.Final.jar:3.2.2.Final]
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
How to reproduce the issue using our tutorial deployment?
- This issue can be reproduced by configuring a Debezium PostgreSQL connector to use a replication slot that is currently active by another database session. This can happen if:
-
- The Kafka broker is shut down or becomes unreachable for a period of time while the connector is operational. This disrupts the connector's heartbeat and communication, often leading to a network-level disconnect from PostgreSQL that leaves the replication slot in an active state, owned by the now-defunct database process (PID 113). When the connector restores the connection to the broker and attempts to resume streaming, it cannot reacquire its own slot.
