anchor.diff:  
   ==== Configuration and startup errors
   
  -The connector will fail upon startup, report an error/exception in the log, and stop running when the connector's configuration is invalid, when the connector cannot successfully connect to PostgreSQL using the specified connectivity parameters, or when the connector is restarting from a previously-recorded position in the PostgreSQL WAL (via the LSN value) and PostgreSQL no longer has that history available. 
  +The connector will fail upon startup, report an error/exception in the log, and stop running when the connector's configuration is invalid, when the connector cannot successfully connect to PostgreSQL using the specified connectivity parameters, or when the connector is restarting from a previously-recorded position in the PostgreSQL WAL (via the LSN value) and PostgreSQL no longer has that history available.
   
   In these cases, the error will have more details about the problem and possibly a suggested work around. The connector can be restarted when the configuration has been corrected or the PostgreSQL problem has been addressed.
   
   ==== PostgreSQL becomes unavailable
   
  -Once the connector is running, if the PostgreSQL server it has been connected to becomes unavailable for any reason, the connector will fail with an error and the connector will stop. Simply restart the connector when the server is available. 
  +Once the connector is running, if the PostgreSQL server it has been connected to becomes unavailable for any reason, the connector will fail with an error and the connector will stop. Simply restart the connector when the server is available.
   
   The PostgreSQL connector stores externally the last processed offset (in the form of a PostgreSQL `log sequence number` value). Once a connector is restarted and connects to a server instance, if it has a previously stored offset it will ask the server to continue streaming from that particular offset. However, depending on the server configuration, this particular offset may or may not be available in the server's write-ahead log segments. If it is available, then the connector will simply resume streaming changes without missing anything. If however this information is not available, the connector cannot relay back the changes that occurred while it was not online.
   
  
positive.code: |Default
  |Description
  
  |`snapshot.mode` 
  |`initial`
  |Specifies the criteria for running a snapshot upon startup of the connector. The default is *initial*, and specifies the connector can run a snapshot only when no offsets have been recorded for the logical server name. The *always* option specifies that the connector run a snapshot each time on startup. The *never* option specifies that the connect should never use snapshots and that upon first startup with a logical server name the connector should read from either from where it last left off (last LSN position) or start from the beginning from the point of the view of the logical replication slot. Finally, the *initial_only* option specifies that the connector should only take an initial snapshot and then stop, without processing any subsequent changes. See link:#snapshots[snapshosts] 
  
  |`snapshot.lock.timeout.ms` 
  |`10000`
  |Positive integer value that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If table locks cannot be aquired in this time interval, the snapshot will fail See link:#snapshots[snapshosts] 
  
  |`rows.fetch.size` 
  |`10240`
  |Positive integer value that specifies the maximum number of rows that should be read from each table while taking a snapshot
  
  |`max.queue.size` 
  |`20240`
  |Positive integer value that specifies the maximum size of the blocking queue into which change events received via streaming replication are placed before they are written to Kafka. This queue can provide backpressure when, for example, writes to Kafka are slower or if Kafka is not available.
  
  |`max.batch.size` 
  |`10240`
  |Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. 
  
  |`poll.interval.ms` 
  |`1000`
  |Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. Defaults to 1000 milliseconds, or 1 second.
  
  |=======================
  
  The connector also supports _pass-through_ configuration properties that are used when creating the Kafka producer and consumer. 
  
  Be sure to consult the http://kafka.apache.org/documentation.html[Kafka documentation] for all of the configuration properties for Kafka producers and consumers. (The PostgreSQL connector does use the http://kafka.apache.org/documentation.html#newconsumerconfigs[new consumer].)
negative.code: The value of the change event message is a bit more complicated. Like the key message, it has a _schema_ section and _payload_ section. The payload section of every change event value produced by the PostgreSQL connector has an _envelope_ structure with the following fields:
  
  * `op` is a mandatory field that contains a string value describing the type of operation. Values for the PostgreSQL connector are `c` for create (or insert), `u` for update, `d` for delete, and `r` for read (in the case of a snapshot).
  * `before` is an optional field that if present contains the state of the row _before_ the event occurred. The structure will  be described by the `PostgreSQL_server.public.customers.Value` Kafka Connect schema, which the `PostgreSQL_server` connector uses for all rows in the `public.customers` table.
  
  [WARNING]
  ====
  Whether or not this field is available is highly dependent on the link:#replica-identity[_REPLICA IDENTITY_] setting for each table
  ====
  
  * `after` is an optional field that if present contains the state of the row _after_ the event occurred. The structure is describe by the same `PostgreSQL_server.public.customers.Value` Kafka Connect schema used in `before`.
  * `source` is a mandatory field that contains a structure describing the source metadata for the event, which in the case of PostgreSQL contains several fields: the connector name, whether the event is part of an ongoing snapshot or not and the same fields from the record's link:#meta-info[_meta information_] section
  * `ts_ms` is optional and if present contains the time (using the system clock in the JVM running the Kafka Connect task) at which the connector processed the event.
  
  And of course, the _schema_ portion of the event message's value contains a schema that describes this envelope structure and the nested fields within it.
  
  