anchor.diff:  
   == Summary
   
  -In this blog post, we have discussed the motivation for incremental snapshotting.
  +In this blog post, we have discussed the motivation for the notion of incremental snapshotting,
  +as introduced by the DBLog paper.
   We have reviewed the methods used in the past to achieve the described functionality.
  -Then we dived into the deep waters of the implementation and in the end, we tried to use it live.
  -
  -We hope you will find the incremental snapshotting useful and we look forward to your feedback, experiences, and use cases.
  +Then we dived into the deep waters of the implementation of this novel snapshotting approach in Debezium, and in the end we tried to use it live.
  +
  +We hope you will find incremental snapshotting useful and we look forward to your feedback, experiences, and use cases.
  +In a future blog post, we'll talk about the support for incremental snaphots of read-only databases
  +(supported by the Debezium MySQL connector as of version 1.7) and how to trigger ad-hoc snapshots using a Kafka topic as the means of signalling instead of a database table.
  
positive.code:     --topic dbserver1.inventory.orders
  ----
  
  Start an incremental ad-hoc snapshot via sending a signal.
  The snapshot messages for the `orders` table are delivered to the `dbserver1.inventory.orders` topic.
  Messages for the `customers` table are delivered without interruption.
  
  
negative.code: EOF
  ----
  
  From the log we see that as per the `table.include.list` setting only one table is snapshotted, `customers`:
  
  ----
  connect_1    | 2021-09-24 13:38:21,781 INFO   Postgres|dbserver1|snapshot  Snapshotting contents of 1 tables while still in transaction   [io.debezium.relational.RelationalSnapshotChangeEventSource]
  