anchor.diff:  
   |===
   
  -The last option for `decimal.handling.mode` configuration property is `string`. In this case the connector will represent all `DECIMAL` and `NUMERIC` values as their formatted string representation and encodes them as follows:
  -
  -[cols="15%a,15%a,35%a,35%a"]
  +The last possible setting for the `decimal.handling.mode` configuration property is `string`. In this case, the connector represents `DECIMAL` and `NUMERIC` values as their formatted string representation, and encodes them as shown in the following table. 
  +
  +.Mappings when `decimal.handling.mode` is `string`
  +[cols="15%a,15%a,35%a,35%a",options="header"]
   |===
   |PostgreSQL Data Type
   |Literal type (schema type)
  
positive.code: ====
  endif::community[]
  
  // Type: continue
  === Kafka Connect process stops gracefully
  
  Suppose that Kafka Connect is being run in distributed mode and a Kafka Connect process is stopped gracefully. Prior to shutting down that process, Kafka Connect migrates all of the process' connector tasks to another Kafka Connect process in that group. The new connector tasks start processing exactly where the prior tasks stopped. There is a short delay in processing while the connector tasks are stopped gracefully and restarted on the new processes.
  
  // Type: continue
  === Kafka Connect process crashes
  
  If the Kafka Connector process stops unexpectedly, then any connector tasks it was running terminate without recording their most recently processed offsets. When Kafka Connect is being run in distributed mode, Kafka Connect restarts those connector tasks on other processes. However, PostgreSQL connectors resume from the last offset that was _recorded_ by the earlier processes. This means that the new replacement tasks might generate some of the same change events that were processed just prior to the crash. The number of duplicate events depends on the offset flush period and the volume of data changes just before the crash.
  
  Because there is a chance that some events might be duplicated during a recovery from failure, consumers should always anticipate some duplicate events. {prodname} changes are idempotent, so a sequence of events always results in the same state.
  
  In each change event record, {prodname} connectors insert source-specific information about the origin of the event, including the PostgreSQL server's time of the event, the ID of the server transaction, and the position in the write-ahead log where the transaction changes were written. Consumers can keep track of this information, especially the LSN, to determine whether an event is a duplicate. 
  
  // Type: continue
  === Kafka becomes unavailable
  
  As the connector generates change events, the Kafka Connect framework records those events in Kafka by using the Kafka producer API. Periodically, at a frequency that you specify in the Kafka Connect worker configuration, Kafka Connect records the latest offset that appears in those change events. If the Kafka brokers become unavailable, the Kafka Connect worker process that is running the connectors repeatedly tries to reconnect to the Kafka brokers. In other words, the connector tasks pause until a connection can be re-established, at which point the connectors resume exactly where they left off.
  
  // Type: continue
  === Connector is stopped for a duration
  
  If the connector is gracefully stopped, the database can continue to be used. Any changes are recorded in the PostgreSQL WAL. When the connector restarts, it resumes streaming changes where it left off. That is, it generates change event records for all database changes that were made while the connector was stopped.
  
negative.code: The connector relies on and reflects the PostgreSQL logical decoding feature, which has the following limitations:
  
  * Logical decoding does not support DDL changes. This means that the connector is unable to report DDL change events back to consumers.
  * Logical decoding replication slots are supported on only `primary` servers. When there is a cluster of PostgreSQL servers, the connector can run on only the active `primary` server. It cannot run on `hot` or `warm` standby replicas. If the `primary` server fails or is demoted, the connector stops. After the `primary` server has recovered, you can restart the connector. If a different PostgreSQL server has been promoted to `primary`, adjust the connector configuration before restarting the connector. 
  
  {link-prefix}:{link-postgresql-connector}#postgresql-when-things-go-wrong[ Behavior when things go wrong] describes what the connector does when there is a problem. 
  ====
  
  [IMPORTANT]
  ====
  {prodname} currently supports databases with UTF-8 character encoding only.
  With a single byte character encoding, it is not possible to correctly process strings that contain extended ASCII code characters.
  ====
  
  // Type: assembly
  