anchor.diff:  
   Debezium's PostgreSQL connector contains two different parts which work together in order to be able to read and process server changes:
   
  -* a https://github.com/debezium/postgres-decoderbufs[_logical decoding output plugin_] which has to be installed and configured in the PostgreSQL server
  +* a logical decoding output plugin which has to be installed and configured in the PostgreSQL server, one of
  +** https://github.com/debezium/postgres-decoderbufs[Protobuf based]
  +** https://github.com/eulerto/wal2json[wal2json]
   * Java code which reads the changes produced by the plugin in Protobuf format, using PostgreSQL's https://www.postgresql.org/docs/9.6/static/logicaldecoding-walsender.html[_streaming replication protocol_], via the PostgreSQL https://github.com/pgjdbc/pgjdbc[_JDBC driver_]
   
   The connector then produces a _change event_ for every row-level insert, update, and delete operation that was received, recording all the change events for each table in a separate Kafka topic. Your client applications read the Kafka topics that correspond to the database tables they're interested in following, and react to every row-level event it sees in those topics.
  
positive.code: 
  |`plugin.name`
  |`decoderbufs`
  |The name of the Postgres link:#output-plugin[logical decoding plugin] installed on the server.
  
  |`slot.name`
  |`debezium`
  
negative.code: 
  . install the link:#output-plugin[logical decoding plugin]
  . configure the link:#server-configuration[PostgreSQL server] to support logical replication
  . create a link:#example-configuration[configuration file for the PostgreSQL Connector] and use the http://docs.confluent.io/{confluent-platform-version}/connect/userguide.html#rest-interface[Kafka Connect REST API] to add that connector to your Kafka Connect cluster.
  
  When the connector starts, it will grab a consistent snapshot of the databases in your PostgreSQL server and start streaming changes, producing events for every inserted, updated, and deleted row. You can also choose to produce events for a subset of the schemas and tables. Optionally ignore, mask, or truncate columns that are sensitive, too large, or not needed.
  
  