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?

io.debezium.connector.postgresql.PostgresConnector
version: 3.2

What is the connector configuration?

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
name: debezium-connector-olpqa-discard-test
namespace: colp-loadenv
labels:
strimzi.io/cluster: kafka-connect-dba-colp
spec:
class: io.debezium.connector.postgresql.PostgresConnector
tasksMax: 1
config:
tasks.max: 1

1. Full load on first run, then CDC
   snapshot.mode: configuration_based
   snapshot.mode.configuration.based.snapshot.schema: true
   snapshot.mode.configuration.based.snapshot.data: false
   snapshot.mode.configuration.based.start.stream: true
   #incremental.snapshot.enabled: true
   incremental.snapshot.chunk.size: 10000
   snapshot.fetch.size: 20000
   snapshot.max.threads: 3

#Debezium Engine/Queing Settings
max.batch.size: 8192
max.queue.size: 65536
max.queue.size.in.bytes: 536870912#512MB
 

1. Schema refresh for DDL changes
   schema.refresh.interval.ms: 10000
    
2. Capture DDL events
   include.schema.changes: true
   plugin.name: pgoutput
   publication.name: app_pub
   database.hostname: dbhost
   database.port: 5432
   database.user: ${secrets:dba-debezium/colp-dba-secret:username}
   database.password: ${secrets:dba-debezium/colp-dba-secret:password}
   database.dbname: olpqa-db-aurora
   publish.via.partition.root: true
   topic.prefix: olpqa-discard-test
   topic.creation.enable: true
   topic.creation.default.replication.factor: -1
   topic.creation.default.partitions: -1
   topic.creation.default.retention.ms: 1209600000
   topic.creation.default.max.message.bytes: 4194304
   schema.include.list: discard
   table.include.list: discard.orders,discard.order_items
3. Replication slot configuration
   slot.name: app_pub
    
4. keep failing on real errors
   errors.tolerance: none
5. be more patient with transient failures (incl. SR connect failures)
   errors.retry.timeout: 600000# 10m total retry budget (pick your SLO)
   errors.retry.delay.max.ms: 30000# backoff cap between retries (e.g., 30s)
6. optional: better logs while it retries
   errors.log.enable: true
   errors.log.include.messages: true

1. Signal configuration for incremental snapshots
   signal.kafka.bootstrap.servers: boot-mn3.stagemskexpresscluste.881mqu.c16.kafka.us-east-1.amazonaws.com:9096,boot-fsk.stagemskexpresscluste.881mqu.c16.kafka.us-east-1.amazonaws.com:9096,boot-avg.stagemskexpresscluste.881mqu.c16.kafka.us-east-1.amazonaws.com:9096
   signal.kafka.topic: olpqa-discard.signal
   signal.enabled.channels: source,kafka
   signal.data.collection: discard.debezium_discard_configbased_signal
   signal.consumer.security.protocol: SASL_SSL
   signal.consumer.sasl.mechanism: SCRAM-SHA-512
   signal.consumer.sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required username=cdo password=${secrets:dba-debezium/msk-secret-kafka:kafka-connect-msk-password};
   signal.producer.security.protocol: SASL_SSL
   signal.producer.sasl.mechanism: SCRAM-SHA-512
   signal.producer.sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required username=cdo password=${secrets:dba-debezium/msk-secret-kafka:kafka-connect-msk-password};

   What is the captured database version and mode of deployment?

(E.g. on-premises, with a specific cloud provider, etc.)

Aurora postgres "16.6.3"

What behavior do you expect?

We want the incremental snapshot to start by inserting a record into the source table or the signal topic. 

What behavior do you see?

with Source: When we insert a record into the table, debezium doesn't even pick up the message and start the initial load:

INSERT INTO discard.debezium_discard_configbased_signal (id, type, data)
VALUES (
  'backfill-2025-09-23-01',
  'execute-snapshot',
  '

{"type":"incremental","data-collections":["discard.orders","discard.order_items"]}

'
);
 
With Kafka: When a message was published, we see the message gets picked up and inserts two rows in the the database signal table as:

"backfill-2025-09-23-01" "execute-snapshot" "

{""type"":""incremental"",""data-collections"":[""discard.orders"",""discard.order_items""]}

"
"5ae7e50a-8d7f-4245-8042-62de5be72715-open" "snapshot-window-open" "{""openWindowTimestamp"": ""2025-09-23T18:49:58.124690769Z""}"
"5ae7e50a-8d7f-4245-8042-62de5be72715-close" "snapshot-window-close" "{""openWindowTimestamp"": ""2025-09-23T18:49:58.124690769Z"", ""closeWindowTimestamp"": ""2025-09-23T18:49:58.341435949Z""}"

Do you see the same behaviour using the latest released Debezium version?

We haven't tested with any other version as 3.2 seems the latest one.

Do you have the connector logs, ideally from start till finish?

(You might be asked later to provide DEBUG/TRACE level log)

Yes.

How to reproduce the issue using our tutorial deployment?

<Your answer>

Feature request or enhancement

For feature requests or enhancements, provide this information, please:

Which use case/requirement will be addressed by the proposed feature?

<Your answer>

Implementation ideas (optional)

<Your answer>