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: 
  . 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/3.0.0/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.
  
  
negative.code: 
  The PostgreSQL connector will typically spend the vast majority of its time streaming changes from the PostgreSQL server to which it is connected. This mechanism relies on https://www.postgresql.org/docs/9.6/static/protocol-replication.html[_PostgreSQL's replication protocol_] where the client can receive changes from the server as they are committed in the server's transaction log at certain positions (also known as `Log Sequence Numbers` or in short LSNs)
  
  Whenever the server commits a transaction, a separate server process invokes a callback function from the link:#output-plugin[logical decoding plugin]. This function processes the changes from the transaction, converts them to a specific  format (Protobuf or JSON in the case of Debezium plugin) and writes them on an output stream which can then be consumed by clients.
  
  The PostgreSQL connector acts as a PostgreSQL client, and when it receives these changes it transforms the events into Debezium _create_, _update_, or _delete_ events that include the LSN position of the event. The PostgreSQL connector forwards these change events to the Kafka Connect framework (running in the same process), which then asynchronously writes them in the same order to the appropriate Kafka topic. Kafka Connect uses the term _offset_ for the source-specific position information that Debezium includes with each event, and Kafka Connect periodically records the most recent offset in another Kafka topic.
  
  