anchor.diff:  [[postgresql-tombstone-events]]
   .Tombstone events
   When a row is deleted, the _delete_ event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be `null`. To make this possible, the PostgreSQL connector follows a _delete_ event with a special _tombstone_ event that has the same key but a `null` value.
  +
  +// Type: continue
  +[[postgresql-truncate-events]]
  +=== _truncate_ events
  +
  +A  _truncate_ change event signals that a table has been truncated.
  +The message key is `null` in this case, the message value looks like this:
  +
  +[source,json,indent=0,subs="+attributes"]
  +----
  +{
  +    "schema": { ... },
  +    "payload": {
  +        "source": { // <1>
  +            "version": "{debezium-version}",
  +            "connector": "postgresql",
  +            "name": "PostgreSQL_server",
  +            "ts_ms": 1559033904863,
  +            "snapshot": false,
  +            "db": "postgres",
  +            "schema": "public",
  +            "table": "customers",
  +            "txId": 556,
  +            "lsn": 46523128,
  +            "xmin": null
  +        },
  +        "op": "t", // <2>
  +        "ts_ms": 1559033904961 // <3>
  +    }
  +}
  +----
  +
  +.Descriptions of _truncate_ event value fields
  +[cols="1,2,7",options="header"]
  +|===
  +|Item |Field name |Description
  +
  +|1
  +|`source`
  +a|Mandatory field that describes the source metadata for the event. In a _truncate_ event value, the `source` field structure is the same as for _create_, _update_, and _delete_ events for the same table, provides this metadata: 
  +
  +* {prodname} version
  +* Connector type and name
  +* Database and table that contains the new row
  +* Schema name
  +* If the event was part of a snapshot (alwas `false` for _delete_ events)
  +* ID of the transaction in which the operation was performed
  +* Offset of the operation in the database log
  +* Timestamp for when the change was made in the database
  +
  +|2
  +|`op`
  +a|Mandatory string that describes the type of operation. The `op` field value is `t`, signifying that this table was truncated.
  +
  +|3
  +|`ts_ms`
  +a|Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task.  +
  + +
  +In the `source` object, `ts_ms` indicates the time that the change was made in the database. By comparing the value for `payload.source.ts_ms` with the value for `payload.ts_ms`, you can determine the lag between the source database update and {prodname}.
  +
  +|===
  +
  +In case a single `TRUNCATE` statement applies to multiple tables,
  +one _truncate_ change event record for each truncated table will be emitted.
  +
  +Note that since _truncate_ events represent a change made to an entire table and don't have a message key,
  +unless you're working with topics with a single partition,
  +there are no ordering guarantees for the change events pertaining to a table (_create_, _update_, etc.) and _truncate_ events for that table.
  +For instance a consumer may receive an _update_ event only after a _truncate_ event for that table,
  +when those events are read from different partitions.
   
   // Type: reference
   // ModuleID: how-debezium-postgresql-connectors-map-data-types
  
positive.code:             "connector": "postgresql",
              "name": "PostgreSQL_server",
              "ts_ms": 1559033904863,
              "snapshot": null,
              "db": "postgres",
              "schema": "public",
              "table": "customers",
  
negative.code: 
  * {prodname} version
  * Connector type and name
  * Database and table that contained the deleted row
  * Schema name
  * If the event was part of a snapshot (alwas `false` for _delete_ events)
  * ID of the transaction in which the operation was performed
  * Offset of the operation in the database log
  * Timestamp for when the change was made in the database
  