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?

PostgreSQL

What is the connector configuration?

Running Debezium server standalone inside K8s but I don't think this is relevant for this scenario.
We have set the `message.key.columns` property to add 1 new column to the keys of some records. The PK of the table is formed from 2 columns, `id` and `account_id` and we have added a 3rd column `ticket_id` which is not part of the PK. All columns are of type Integer.

What is the captured database version and mode of depoyment?

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

PostgreSQL 14

What behaviour do you expect?

• Break hard?
• Or at least have this behaviour documented for better visibility or at least mention in the docs that it is recommended to have replica identity set to FULL when this property is used.

What behaviour do you see?

Adding extra columns to the key via `message.key.columns` property that are not part of the PK of the table and having the table with REPLICA IDENTITY as DEFAULT, when a delete happens, the value for the non PK column, in this case `ticket_id` will have the default value being set to 0.

While I understand the reason behind this, as with REPLICA IDENTITY as DEFAULT, on a delete operation, we can't extract the value of the column, silently setting it to default value 0 is weird behaviour, especially when Kafka is used as a sink and tombstones won't work in this case because the generated tombstone will have a different key.

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

(Ideally, also verify with latest Alpha/Beta/CR version)

Dit not tested 2.0 version, only 1.9.

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

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

N/A

How to reproduce the issue using our tutorial deployment?

1. Add a new column to the key which is not part of the PK of the table
2. Delete a record
3. Check the generated records and their keys

Feature request or enhancement

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

I am not sure what can be done here, but at least this should be documented.

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

• Tombstones records won't be buggy when Kafka is used as a sink.

Implementation ideas (optional)

• Improve documentation.