-
Enhancement
-
Resolution: Done
-
Minor
-
3.0.0.Alpha1
-
None
-
False
-
None
-
False
In the Postgres connector, the command to create a replication slot halts if there is a long-running query/transaction on the database. The replication slot is only created once the query completes.
When transactions span several minutes, the connector remains stuck in the slot creation command, leading to a poor user experience as users wait for the connector to start without knowing about this limitation.
This change introduces a timeout for the replication slot creation command. The default timeout can be set to 90 seconds. If the command exceeds the timeout, the task should throw a RetriableException, so that the operation can be retried and the user would know about the reason for the delay in task creation.
[DBZ-8073] Introduce timeout for replication slot creation
Rajendra Dangwal
added a comment - rk3rn3r there is no default timeout set for the replication slot creation command. It will remain stuck as long as there is an open transaction on the DB. Hence, we are introducing the timeout.
Rajendra Dangwal
added a comment - rk3rn3r there is no default timeout set for the replication slot creation command. It will remain stuck as long as there is an open transaction on the DB. Hence, we are introducing the timeout. A quick question: Before adding a new timeout config and changing a default value (which might be set for reasons), wouldn't be throwing a `RetriableException` be sufficient enough?
Bernd Helmle
added a comment - As noted in Zulip an alternative approach could be to pass a configurable `lock_timeout` session parameter value to the PostgreSQL replication session within `createReplicationSlot()` and let PostgreSQL do the timeout legwork on the connection. That throws a `55P03`, lock_not_available` error and should be catched accordingly. Though `createReplicationSlot()` needs to `RESET` the `lock_timeout` in any case. Here is an example session with psql:
LANG=C PGOPTIONS=--lc-messages=C psql -q "replication=database" bernd@localhost:bernd :1 #= \set VERBOSITY verbose bernd@localhost:bernd :1 #= SET lock_timeout TO '5s'; Time: 0.426 ms bernd@localhost:bernd :1 #= CREATE_REPLICATION_SLOT test2 LOGICAL pgoutput; ERROR: 55P03: canceling statement due to lock timeout LOCATION: ProcessInterrupts, postgres.c:3359
Bernd Helmle
added a comment - As noted in Zulip an alternative approach could be to pass a configurable `lock_timeout` session parameter value to the PostgreSQL replication session within `createReplicationSlot()` and let PostgreSQL do the timeout legwork on the connection. That throws a `55P03`, lock_not_available` error and should be catched accordingly. Though `createReplicationSlot()` needs to `RESET` the `lock_timeout` in any case. Here is an example session with psql:
LANG=C PGOPTIONS=--lc-messages=C psql -q "replication=database"
bernd@localhost:bernd :1 #= \set VERBOSITY verbose
bernd@localhost:bernd :1 #= SET lock_timeout TO '5s' ;
Time: 0.426 ms
bernd@localhost:bernd :1 #= CREATE_REPLICATION_SLOT test2 LOGICAL pgoutput;
ERROR: 55P03: canceling statement due to lock timeout
LOCATION: ProcessInterrupts, postgres.c:3359
Rajendra Dangwal
added a comment - I will be raising a PR soon. 
Released